We have a release pipeline that is failing with following message:
resource ID for resource type 'Microsoft.Web/Sites' and resource name
'appservicename'. Error: Could not fetch access token for Managed
Service Principal. Please configure Managed Service Identity (MSI) for
virtual machine 'https://aka.ms/azure-msi-docs'. Status code: 400,
status message: Bad Request
We have 2 different service connections:
Azure Resource Manager using service principal authentication
Azure Resource Manager using managed identity authentication
The first one works like a charm. However, because the developer wanted to limit admin access on the Azure AD, he tried creating a managed identity authentication service connection which at first glance, since it allowed us to select the App Service, appeared to indicate it's working, until an actual deployment was triggered and it failed per the error message above.
After numerous searches online, I think this answer may be the clue to why this is failing with the managed identity authentication service connection yet succeeding with the service principal connection just fine.
I just want to confirm, is this truly the case? that a hosted agent doesn't support MSI based authentication, which is what we are using… or has that changed?
We are indeed using Microsoft agent pool.
It doesn't make sense for our app service to use a VM at this time. The use case just isn't applicable for the dashboards we have.
As it is written in the docs:
You are required to use a self-hosted agent on an Azure VM in order to use managed service identity
I assume that it was alway like that. Here we are talking abut MSI assigned to VM which serves as build agent. Not MSI which is identity of App Service. Why? Service Connection is an abstraction which makes easy authentication to your Azure Subscription. So it gives identity to VM and then when your perform some action against your Azure thanks to MSI Azure know that can perform that action. Another aption is authentication via Service Principal, but thi can be done from any VM (inlcuding MS Hosted) because it relies on Client Id and Client secret which is kept in service connections. And MSI have to be assigned to particular VM which cannot be done with MS Hosted agents.
Related
i have an app (stateless) running as C# executable in my SF cluster. the App uses Managed identity to connect to Azure Key Vault. i have granted Key vault accss policy to the Virtual Machine Scale set managed identity, but when app tries to connect to Key vault, it gets exeption
" Azure.Identity.AuthenticationFailedException (-2146233088)
DefaultAzureCredential failed to retrieve a token from the included credentials.
EnvironmentCredential authentication unavailable. Environment variables are not fully configured?
Most of the articles talks about this exception when running on local machine. But i am running SF on azure, but still getting exception.
Any pointers on how to troubleshoot further.
I am just new to Azure Cloud and Devops, so forgive me if I may forget some critical info here.
So during creation of tasks for the release and selecting subscriptions, I get an error when trying to authorize the subscription (which I suspect is because of insufficient permissions associated to my account), so I go to advanced options to select the managed identity authentication.
After which no error shows now. So I set all remaining items and assign Deploy Azure App Service task. However during the running of the agent I get an error during Deploy Azure App Service step.
Error: Failed to get resource ID for resource type 'Microsoft.Web/Sites' and resource name 'sample-vue'. Error: Could not fetch access token for Managed Service Principal. Please configure Managed Service Identity (MSI) for virtual machine 'https://aka.ms/azure-msi-docs'. Status code: 400, status message: Bad Request
I have already set my azure app service to have a system assigned managed identity, but still this error occurs. I can't find any answer, online, with regards to the error above so hoping that someone could help explain to me the problem and how to possibly fix it. My hunch now is that I may have some insufficient permissions, but I don't know what it may be.
Please try the following items:
Remove and re-add the service connection in DevOps.
Check the rights of the account on Azure subscription. Please verify if the account has at least contributor access on Azure subscriptions. Check https://learn.microsoft.com/en-us/azure/billing/billing-add-change-azure-subscription-administrator
Will kubernetes service connections in azure devops work with an AKS cluster that is bound to AAD via openidconnect? Logging into such clusters goes through an openidconnect flow that involves a device login + browser. How is this possible w/ azure devops k8s service connections?
Will kubernetes service connections in azure devops work with an AKS
cluster that is bound to AAD via openidconnect?
Unfortunately to say, no, this does not support until now.
According to your description, what you want to connect with in Azure Devops Kubernetes service connection is Azure Kubernetes service. This means you would select Azure Subscription in Choose authentication. BUT, this connection method is using Service Principal Authentication (SPA) to authenticate, which does not yet supported for the AKS that is bound with AAD auth.
If you connect your AKS cluster as part of your CI/CD deployment in Azure Devops, and attempt to get the cluster credentials. You would get a warning response which inform you to log in since the service principal cannot handle it:
WARNING: To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code *** to authenticate.
You should familiar with this message, it needs you open a browser to login in to complete the device code authentication manually. But this could not be achieve in Azure Devops.
There has a such feature request raised on our forum which request us expand this feature to Support non-interactive login for AAD-integrated clusters. You can vote and comment there to advance the priority of this suggestion ticket. Then it could be considered into the develop plan by our Product Manager as soon as possible.
Though it could not be achieved directly. But there has 2 work around can for you refer now.
The first work around is change the Azure DevOps authenticate itself from AAD client to the server client.
Use az aks get-credentials command and specify the parameter --admin with it. This can help with bypassing the Azure AD auth since it can let you connect and retrieve the admin credentials which can work without Azure AD.
But, I do not recommend this method because subjectively, this method is ignoring the authentication rules set in AAD for security. If you want a quick method to achieve what you want and not too worry about the security, you can try with this.
The second one is using Kubernetes service accounts
You can follow this doc to create a service account. Then in Azure Devops, we could use this service account to communicate with AKS API. Here you also need to consider about the authorized IP address ranges in AKS.
After the service account created successfully, choose Service account in the service connection of Azure Devops:
Server URL: Get it from the AKS instance(API server address) in Azure portal, then do not forget append the https:// before it while you input it into this service connection.
Secret: Generate it by using command:
kubectl get secret -n <name of secret> -o yaml -n service-accounts
See this doc: Deploy Vault on Azure Kubernetes Service (AKS).
Then you can use this service connection in Azure Devops tasks.
We currently have one DevOps repository, with a functional CI/CD pipeline. We have another website hosted on a different instance (and different region) on Azure. We are trying to use our existing repo to deploy to the other Azure instance, but it is giving is the following message:
Failed to query service connection API: 'https://management.azure.com/subscriptions/c50b0601-a951-446c-b637-afa8d6bb1a1d?api-version=2016-06-01'. Status Code: 'Forbidden', Response from server: '{"error":{"code":"AuthorizationFailed","message":"The client '2317de35-b2c2-4e32-a922-e0d076a429f5' with object id '2317de35-b2c2-4e32-a922-e0d076a429f5' does not have authorization to perform action 'Microsoft.Resources/subscriptions/read' over scope '/subscriptions/c50b0601-a951-446c-b637-afa8d6bb1a1d'."}}'
I have tried all of the recommended trouble-shooting, making sure that the user is in a Global Administrator role and what-not, but still not luck. The secondary Azure subscription that we are hoping to push our builds to is a trial account. I'm not sure if it being a trial account matters.
I came across the same error. It turns out that, as the error message states, the service principal didn't have Read permission over the subscription. So the solution was to go to Azure Portal, select the subscription, select IAM and assign the role Reader to my service principal. Full explanation on here:
https://clydedz.medium.com/connecting-azure-devops-with-azure-46a908e3048f
I have the same problem. There are one repository and two instances of the application on the Azure portal. For the first instance, the subscription Pay-As-You-Go is used, and there were no problems for it when creating the service connection and CI/CD settings. For the second instance, a free subscription is used and when trying to create a new service connection (Azure Resource Manager) I get the same error.
I tried to do it with the permissions of Owner and Contributor
UPD: I was helped by the re-creation of the application in the azure portal
https://learn.microsoft.com/en-ca/azure/active-directory/develop/howto-create-service-principal-portal
Another option would be to save without verification if the Service Principle will not require permissions at the Subscription level. Like for example providing access to a Keyvault.
Check if the service connection for the second instance is correctly added in project settings:
My requirement is, need to launch an AWS EC2 Instance through REST API while TFS running.
For that I need to register the API in TFS as Generic Service Endpoint.
I am not aware how to add the API endpoint because the endpoint contains many header values and signatures.
I hope we can pass the Signature in token.
But what need to pass for UserName?
Could anyone know how to register the AWS REST API in TFS service Endpoint.?
You should do this task via powershell script and just add a powershell step in the TFS build/release workflow. You have flexibility to run it via powershell command line without the TFS web UI. Also the script is portable. It can be invoked in TFS,Jenkins, etc.
It's not able to register aws ec2 instance API in TFS Generic Service Endpoint.
You could use a powershell script to authenticate with AWS API to launch a EC2 instance and invoke the REST API from your Build Pipeline.
Besides, you could use AWS Tools for Microsoft Visual Studio Team Services.
This tool include a new service endpoint type, AWS, to supply AWS credentials to the tasks at runtime.
It will create an AWS Credentials Connection. Select the AWS endpoint type and provide the following parameters:
A name used to refer to the credentials when configuring tasks that
require AWS credentials
AWS Access Key ID
AWS Secret Access Key
After an AWS subscription has be linked to Team Foundation Server, you could use the task deploy to Amazon EC2 with AWS CodeDeploy.
Note: Minimum supported environments
Visual Studio Team Services
Team Foundation Server 2015 Update 3 (or higher)