I'm working on a Terraform project in which I setup several Azure resources.
One of these Azure resources is a service principal (linked to an app registration) which I use to deploy my Terraform code in a CI/CD pipeline via Github actions.
When developing locally, I use az login to authenticate, but occasionally I'm receiving an error for the Terraform app service principal. Most of the times, when I re-run terraform apply the error is not raised. Sometimes the error persists for several terraform apply calls.
Error: Retrieving Application with object ID "fe2b93b7-e26c-402c-ab4f-87e3695c1f45" with module.app_registrations.azuread_application.terraform_app on ../modules/app_registrations/terraform.tf line 56, in resource "azuread_application" "terraform_app": 56: resource "azuread_application" "terraform_app" { ApplicationsClient.BaseClient.Get(): Get "https://graph.microsoft.com/beta/b859b851-97d8-4dc2-bf56-f2a5bc5c494b/applications/fe2b93b7-e26c-402c-ab4f-87e3695c1f45": http: RoundTripper implementation (*retryablehttp.RoundTripper) returned a nil *Response with a nil error
I'm having a hard time to understand why I'm able to generate this service principal using my user credentials via Terraform, but am receiving this retrieval error when refreshing the state of the same service principal. When I'm deploying the Terraform code via Github Actions, which uses the service principal to authenticate, this retrieval error is never raised.
Anyone can point me in the right direction?
I've already added the Application administrator role to my user credentials and added the Application.ReadWrite.All role to the Terraform service principal. Above error when refreshing the state using user credentials via az login persists.
I am trying to understand the overlap between two of those roles in Azure RBAC. Looks like monitor-contributor completely covers application-insights-component-contributor besides "Microsoft.Resources/deployments/*". Considering the following situation whether I am deploying web availability tests into AppInsights resource and the deployment identity is service principal which was already granted monitor-contributor permissions. Should I grant this identity also 'application-insights-component-contributor' to be able to create those resources or 'monitor contributor' is good enough?
1 Edit
I am also deploying alert rules along with the tests and those rules implemented as rm template, if SP was granted monitoring-contributor only it's fails with
Error: requesting Validation for Template Deployment "app508-dfpg-dev3-diag-eastus2-backoffice-ai-test-dep" (Resource Group "app508-dfpg-ne-diag-eastus2"): resources.DeploymentsClient#Validate: Failure sending request: StatusCode=403 -- Original Error: Code="AuthorizationFailed" Message="The client '2c20abbf-e825-495c-9d06-90c5f04f9c60' with object id '2c20abbf-0000-0000-0000-90c5f04f9c60' does not have authorization to perform action 'Microsoft.Resources/deployments/validate/action' over scope '/subscriptions/s/resourcegroups/app508-dfpg-ne-diag-eastus2/providers/Microsoft.Resources/deployments/app508-dfpg-dev3-diag-eastus2-backoffice-ai-test-dep' or the scope is invalid. If access was recently granted, please refresh your credentials."
No need to give the Application Insights Component Contributor role, Monitoring Contributor role is enough. When you deploying the web availability tests, you just need the Microsoft.Insights/webtests/* action permission, it is already included in Monitoring Contributor.
I have a terraform library of different azure resources that were working fine the other day. Since the Azure AD failure I can't run a terraform plan anymore without random application insight resources failing due to 401 Unauthorized
Tried re-running az login but unfortunately still receiving issues.
Every plan is resulting in a different application insight resource throwing a 401.
Error: Error making Read request on AzureRM Application Insights
'{resource-name}': insights.ComponentsClient#Get: Failure responding
to request: StatusCode=401 -- Original Error: autorest/azure: Service
returned an error. Status=401 Code="Unauthorized"
Message="Unauthorized"
InnerError={"diagnosticcontext":"1b8e2cf0-5fd5-4a0d-9b75-1093e63ecd18","time":"2020-09-29T16:32:34.3731943Z"}
Have you tried re-initializing your Terraform backend? Doing this sequence just resolved the issue for me.
az login
terraform init
terraform plan
I'm sitting in a project where I will move from TFS to VSTS so we do have a working release definition.
But when I try deploying a service fabric cluster i get the following error:
2018-08-28T09:02:59.8922249Z ##[error]An error occurred attempting to acquire an Azure Active Directory token. Ensure that your service endpoint is configured properly with valid credentials. Error message: Exception calling "AcquireToken" with "3" argument(s): "AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multi-factor authentication to access '< service principle Id >'.
Trace ID: < guid1 is here >
Correlation ID: < guid2 is here >
Then I go to the azure portal -> AAD -> Sign In -> look up my specific sign in (based on correlation Id) and there it state that Sign-in status is Success
Considering this works for our TFS instance i assume the service principle is correctly set up. But since the build/deploy agents is now on a VM in azure instead of on prem for TFS, is there anything i need to change?
Traffic should be OK, i can navigate to the https-adress to the cluster from the VM with agents.
I've tried google it, but to no success so hopefully someone can point me to the right direction where to look.
And in portal, 'MFA is required' is no, so multi factor should not be neccesary.
Just try using certificate based authentication instead of using AAD Authentication in the service endpoint configuration.
Reference the same issue here: https://github.com/Microsoft/vsts-tasks/issues/7714
If that still not work, just try to create a new endpoint, then try it again.
I have enabled Managed Service Identities on an App Service. However, my WebJobs seem unable to access the keys.
They report:
Tried the following 3 methods to get an access token, but none of them worked.
Parameters: Connectionstring: [No connection string specified], Resource: https://vault.azure.net, Authority: . Exception Message: Tried to get token using Managed Service Identity. Unable to connect to the Managed Service Identity (MSI) endpoint. Please check that you are running on an Azure resource that has MSI setup.
Parameters: Connectionstring: [No connection string specified], Resource: https://vault.azure.net, Authority: https://login.microsoftonline.com/common. Exception Message: Tried to get token using Active Directory Integrated Authentication. Access token could not be acquired. password_required_for_managed_user: Password is required for managed user
Parameters: Connectionstring: [No connection string specified], Resource: https://vault.azure.net, Authority: . Exception Message: Tried to get token using Azure CLI. Access token could not be acquired. 'az' is not recognized as an internal or external command,
Kudo does not show any MSI_ environmental variables.
How is this supposed to work? This is an existing App Service Plan.
The AppAuthentication library leverages an internal endpoint in App Service that receives the tokens on your site's behalf. This endpoint is non-static and therefore is set to an environment variable. After activating MSI for your site through ARM, your site will need to be restarted to get two new Environment Variables set in it:
MSI_ENDPOINT and MSI_SECRET
The presence of these variables are essential to the MSI feature working properly during runtime as the AppAuthentication library uses them to get the authorization token. The error message reflects this:
Exception Message: Tried to get token using Managed Service Identity. Unable to connect to the Managed Service Identity (MSI) endpoint. Please check that you are running on an Azure resource that has MSI setup.
If these variables are absent, you might need to restart the site.
https://learn.microsoft.com/en-us/azure/app-service/app-service-managed-service-identity
If the environment variables are set and you still see the same error, the article above has a code sample showing how to send requests to that endpoint manually.
public static async Task<HttpResponseMessage> GetToken(string resource, string apiversion) {
HttpClient client = new HttpClient();
client.DefaultRequestHeaders.Add("Secret", Environment.GetEnvironmentVariable("MSI_SECRET"));
return await client.GetAsync(String.Format("{0}/?resource={1}&api-version={2}", Environment.GetEnvironmentVariable("MSI_ENDPOINT"), resource, apiversion));
}
I would try that and see what kind of response I get back.
I just solved this issue when trying to use MSI with a Function app, though I already had the environment variables set. I tried restarting multiple times to no success. What I ended up doing was manually turning off MSI for the Function, then re-enabling it. This wasn't ideal, but it worked.
Hope it helps!
I've found out that if you enable MSI and then swap out the slot, the functionality leaves with the slot change. You can re-enable it by switching it off and on again but that will create a new identity in AD and will require you to reset permissions on the key vault for it to work.
Enable the identity and give access to your azure function app in keyvault via access policy.
You can find identity in platform feature tab
These two steps works for me
In my case I had forgotten to add an Access Policy for the application in the Key Vault
Just switched ON the Status like #Sebastian Inones showed.
Than add access policy for KeyVault like
This is resolved the issue!!
For the ones, like my self, wondering how to enable MSI.
My scenario:
I have an App Service already deployed and running for a long time.
In addition, on Azure DevOps I have my Pipeline configured to Auto-Swap my Deployment Slots (Staging/Production). Suddenly, after a normal push, Production starts failing because of the described issue.
So, in order to enable MSI again (I don't know why it has to be re-enabled but I believe this is only a workaround, not a solution, as it should be still enabled in the first place)
Go to your App Service. Then Under Settings --> Identity.
Check the status: In my case, it was off
I have attached an image below to make it easier to follow.
For the folks that will come across these answers, I would like to share my experience.
I got this problem with Azure Synapse pipeline run. Essentially I added access policies properly to the KeyVault, and also I added a LinkedService to the Azure Synapse pointing to my KeyVault.
If I trigger the notebook manually it works, but in the pipeline, it fails.
Initially, I used the following statement:
url = TokenLibrary.getSecret("mykeyvault", "ConnectionString")
Then I added the name of the linked service as a third parameter, and the pipeline was able to leverage that linked service to obtain the MSI token for a Vault.
url = TokenLibrary.getSecret("mykeyvault", "ConnectionString", "AzureKeyVaultLinkedServiceName")
Might be unrelated to your issue but I was getting the same error message.
For me, the issue was using pip3's azure-cli. I was able to fix this issue by using brew packages for both azure-cli and azure-functions-core-tools.
Uninstall pip3 azure-cli
pip3 uninstall azure-cli
Install brew azure-cli
brew update
brew install azure-cli
Double check if the error message ends with:
Please go to Tools->Options->Azure Services Authentication, and re-authenticate the account you want to use.