Terraform azurerm provider tries to register with wrong credentials

Question

I try to run terraform with azurerm provider initialized for service principal authorization, with the following in providers.tf (with service principal that has owner access on the subscription and works in other code):

provider "azurerm" {
  features {}
  subscription_id    = "SSSSSSSS-SSSS-SSSS-SSSS-SSSSSSSSSSSS"
  client_id          = "AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA"
  tenant_id          = "<MY_TENANT_ID>"
  client_secret      = "<MY_CLIENT_SECRET>"
}

However, when I run terraform plan or terraform apply , this fails reporting totally different client ID:

Error: Error ensuring Resource Providers are registered. [.... some lines of useless examples....] Original Error: Cannnot register providers: Microsoft.ServiceFabricMesh, Microsoft.ManagedServices, Microsoft.DesktopVirtualization. Errors were: Cannot register provider Microsoft.ServiceFabricMesh with Azure Resource Manager: resources.ProvidersClient#Register: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client 'BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB' with object id 'BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB' does not have authorization to perform action ' Microsoft.ServiceFabricMesh/register/action' over scope '/subscriptions/SSSSSSSS-SSSS-SSSS-SSSS-SSSSSSSSSSSS' or the scope is invalid. If access was recently granted, please refresh your credentials.".

In other words, while I tell terraform to use service principal "AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA", it uses "BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB" instead.

It is obvious to say that nothing in my code refers a service principal with id "BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB".

Setting ARM_* environment variables does not have any effect on this behavior.

Any idea how could that happen?

Update: I'm on terraform 0.14.3 and azurerm 2.41. Also tried azurerm 2.32 - it behaves the same.

Answer 1

First of all, you can output the client id to make sure that you are using the correct service principal that has the appropriate authorization scope on the subscription and tenant you're working with.

data "azurerm_client_config" "current" {
}

output "account_id" {
  value = data.azurerm_client_config.current.client_id
}

Also, If you're using service principal credentials, try re-generating your secret key or your service principal. As a workaround, you also could skip the provider registration as

provider "azurerm" {
  skip_provider_registration = true
}

At last, try to upgrade your terraform and azurerm provider for a better experience. It might be some bug in some versions, refer to this1 and this2 .

Answer 2

I solved this - but still do not know why incorrect service principal id was used by terraform.

Once I registered the groups manually, the issue with 'BBBBBBBB...' principal id happened once more when terraform tried to create a resource in not existing group (there was a typo in RG name). I still can't understand why terraform reported that weird service principal issue instead of missed group, but the issue has gone now.

Thanks everyone who helped me to narrow it!

Answer 3

https://docs.microsoft.com/en-us/answers/questions/287573/authorization-failed-when-when-writing-a-roleassig.html one of the best answers and apt solution at least for Free trail account