Terraform-provider-azurerm: Configuring the Service Principal in Terraform using arguments isn't working

Created on 7 Sep 2020  ·  10Comments  ·  Source: terraform-providers/terraform-provider-azurerm

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v0.12.18
+ provider.azurerm v2.26.0

Affected Resource(s)

  • provider "azurerm"

Terraform Configuration Files

Used example from the docs: https://www.terraform.io/docs/providers/azurerm/guides/service_principal_client_secret.html#configuring-the-service-principal-in-terraform

provider "azurerm" {
  version = "~> 2.26"

  subscription_id = var.subscription_id
  client_id       = var.client_id
  client_secret   = var.client_secret
  tenant_id       = var.tenant_id

  features {}
}

terraform {
  required_version = "= 0.12.18"
  backend "azurerm" {
    resource_group_name  = "resource_group_name"
    storage_account_name = "storage_account_name"
    container_name       = "container_name"
    key                  = "key"
  }
}

Debug Output

Debug

2020/09/07 17:15:47 [INFO] Terraform version: 0.12.18  
2020/09/07 17:15:47 [INFO] Go runtime version: go1.13.4
2020/09/07 17:15:47 [INFO] CLI args: []string{"/usr/local/bin/terraform", "init"}
2020/09/07 17:15:47 [DEBUG] Attempting to open CLI config file: /Users/test/.terraformrc
2020/09/07 17:15:47 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2020/09/07 17:15:47 [INFO] CLI command args: []string{"init"}
2020/09/07 17:15:47 [DEBUG] Module installer: begin consul
2020/09/07 17:15:47 [DEBUG] Module installer: begin elastic
2020/09/07 17:15:47 [DEBUG] Loading Environment "public"
2020/09/07 17:15:47 Testing if Service Principal / Client Certificate is applicable for Authentication..
2020/09/07 17:15:47 Testing if Multi Tenant Service Principal / Client Secret is applicable for Authentication..
2020/09/07 17:15:47 Testing if Service Principal / Client Secret is applicable for Authentication..
2020/09/07 17:15:47 Testing if Managed Service Identity is applicable for Authentication..
2020/09/07 17:15:47 Testing if Obtaining a token from the Azure CLI is applicable for Authentication..
2020/09/07 17:15:47 Using Obtaining a token from the Azure CLI for Authentication

Panic Output

Expected Behavior

Authentication is successful.

Actual Behavior

Fails to authenticate to Azure. The intention is to use variables to populate the subscription_id, client_id, client_secret and tenant_id arguments. When using environment variables ARM_SUBSCRIPTION_ID, ARM_CLIENT_ID, ARM_CLIENT_SECRET and ARM_TENANT_ID the authentication is successful, so the values are valid. Also tried to configure these variables in-line just for test and still authentication failed.

Steps to Reproduce

  1. Use subscription_id, client_id, client_secret and tenant_id arguments to authenticate to Azure.

  2. terraform plan


Thanks in advance!

authentication question

Most helpful comment

Hi @niskhakova-gitlab @favoretti and @kinwolfqc thanks a lot for the additional information! This makes things a lot different.

A little correction that terraform will use Azure CLI for authentication as the last resort. If every other approach of authentication fails, terraform would use Azure CLI to acquire an access token to authenticate.

The backend block in terraform block should use its own setting of the credentials (please refer to this documentation), like this:

terraform {
  required_version = "~> 0.12.18"
  backend "azurerm" {
    resource_group_name = "arcturus-test"
    subscription_id = "REDACTED"
    client_id       = "REDACTED"
    client_secret   = "REDACTED"
    tenant_id       = "REDACTED"
  }
}

Unfortunately variables are not supported in this block, I have to hard code these in the config. And since I did not set up a storage account or container in this resource group, the terraform init fails for me. But checking the log, the authentication should succeed.

2020/09/10 10:43:33 Testing if Service Principal / Client Certificate is applicable for Authentication..
2020/09/10 10:43:33 Testing if Multi Tenant Service Principal / Client Secret is applicable for Authentication..
2020/09/10 10:43:33 Testing if Service Principal / Client Secret is applicable for Authentication..
2020/09/10 10:43:33 Using Service Principal / Client Secret for Authentication
2020/09/10 10:43:33 Getting OAuth config for endpoint https://login.microsoftonline.com/ with  tenant **REDACTED**

Hope this helps, thanks

All 10 comments

Hi @niskhakova-gitlab thanks for this issue and sorry for the inconvenience!

I just tried the same approach of authentication and it works fine for me. Actually the logic of these parameters is use the assigned value and if assigned value is empty, terraform will get the value from the corresponding environment variables. Therefore using these parameters should be exactly the same as using environment variables.

Based on the debug log, the Service Principal / Client Secret authentication is skipped, and this happens when terraform reads the client_secret is empty and also no env variable ARM_CLIENT_SECRET assigned. Could you please double confirm?

Hi @ArcturusZhang, many thanks for taking a look at this issue. I've checked that client_secret should not be empty and tried to specify all variables in-line just to test and still authentication failed. I've tried to export ARM_CLIENT_SECRET variable and then use the rest of the arguments(subscription_id, client_id, tenant_id) in-line and got the error:

  ----

Initializing the backend...

Error: Error building ARM Config: 3 errors occurred:
        * A Subscription ID must be configured when authenticating as a Service Principal using a Client Secret.
        * A Client ID must be configured when authenticating as a Service Principal using a Client Secret.
        * A Tenant ID must be configured when authenticating as a Service Principal using a Client Secret.

So it's still ignoring all other arguments if they are not exported as env vars, not sure what am I missing here as it appears that doing everything according to the docs. Could you please share your pseudo-code example on how did you setup authentication?

Hi @niskhakova-gitlab my code is very simple just hard-coding all credentials in the provider block:

provider "azurerm" {
    features {}

    subscription_id = "REDACTED"
    client_id = "REDACTED"
    client_secret = "REDACTED"
    tenant_id = "REDACTED"

    version = ">2.0.0"
}

resource "azurerm_resource_group" "test" {
    name = "test-authentication"
    location = "westus2"
}

and I confirm that I do not have environment variables like ARM_SUBSCRIPTION_ID etc.

Could you have a try that to simply your script by just hard-coding all credentials in the provider block?

client_id and client_secret will be populated via az-cli used under the hood, however, if you have access to multiple tenants and subscriptions - it can't make a deterministic choice of what to offer you, so those two should be hardcoded.

I have the exact same problem, it seems to completely ignore the values in the provider block.
I receive this message when running terraform plan: Error building AzureRM Client: Error retrieving the Profile from the Azure CLI: No Subscription was Marked as Default in the Azure Profile. Please re-authenticate usingaz login.

It seems to try to use az cli even though the values are specified in the provider block?
As with the OP, Using the environment variables is working fine with the same values entered, so the problem is not with the values.
Here is my block just to be sure

provider "azurerm" { 
    subscription_id             = "<snip>" 
    client_id                   = "<snip>"
    client_secret               = "<snip>" 
    tenant_id                   = "<snip>" 
    skip_provider_registration  = true

    features {}
} 
terraform {
    required_version = "~>0.12"
    required_providers {
        azurerm = "=2.25.0"
    }
}

@ArcturusZhang, thanks for sharing. I noticed that I've missed terraform section in original Terraform Configuration Files block, sorry for that, updated now. My config file looks similar to the one that @kinwolfqc provided. So without terraform the authentication is working fine. Could you please clarify if it is expected?

Hi @niskhakova-gitlab @favoretti and @kinwolfqc thanks a lot for the additional information! This makes things a lot different.

A little correction that terraform will use Azure CLI for authentication as the last resort. If every other approach of authentication fails, terraform would use Azure CLI to acquire an access token to authenticate.

The backend block in terraform block should use its own setting of the credentials (please refer to this documentation), like this:

terraform {
  required_version = "~> 0.12.18"
  backend "azurerm" {
    resource_group_name = "arcturus-test"
    subscription_id = "REDACTED"
    client_id       = "REDACTED"
    client_secret   = "REDACTED"
    tenant_id       = "REDACTED"
  }
}

Unfortunately variables are not supported in this block, I have to hard code these in the config. And since I did not set up a storage account or container in this resource group, the terraform init fails for me. But checking the log, the authentication should succeed.

2020/09/10 10:43:33 Testing if Service Principal / Client Certificate is applicable for Authentication..
2020/09/10 10:43:33 Testing if Multi Tenant Service Principal / Client Secret is applicable for Authentication..
2020/09/10 10:43:33 Testing if Service Principal / Client Secret is applicable for Authentication..
2020/09/10 10:43:33 Using Service Principal / Client Secret for Authentication
2020/09/10 10:43:33 Getting OAuth config for endpoint https://login.microsoftonline.com/ with  tenant **REDACTED**

Hope this helps, thanks

That helps, many thanks for the clarification @ArcturusZhang!

Closing since this has been resolved

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

Was this page helpful?
0 / 5 - 0 ratings