Azure CLI Authentication does not work when using the Azure CLI task from Azure DevOps

[ghost]

This issue was originally opened by @jlorich as hashicorp/terraform#22002. It was migrated here as a result of the provider split. The original body of the issue is below.

---

While local, terraform uses the Azure CLI authentication without issue. However, in Azure DevOps the executable does not pick up auth from the Azure CLI Task.

Terraform Version

Terraform 0.11.x
AzureRM Provider 1.31.0

Terraform Configuration Files

resource "azurerm_resource_group" "default" {
  name     = "${var.name}-${var.environment}-rg"
  location = "westus"
}

Debug Output

Error: Error building AzureRM Client: Error populating Client ID from the Azure CLI: No Authorization Tokens were found - please ensure the Azure CLI is installed and then log-in with `az login`. |  
-- | --
  |   |  
  | on <empty> line 0: |  
  | (source code not available)

Crash Output

None

Expected Behavior

Auth should work without need to set environment variables

Actual Behavior

Terraform is not authorized

Steps to Reproduce

    # Apply terraform
    - task: AzureCLI@1
      displayName: Terraform Deploy
      inputs:
        azureSubscription: $(azureSubscription)
        scriptLocation: inlineScript
        workingDirectory: $(System.DefaultWorkingDirectory)/terraform/
        addSpnToEnvironment: true
        inlineScript: |
            endDate=`date -d "30 minutes" '+%Y-%m-%dT%H:%MZ'`
            sas=`az storage container generate-sas \
                -n $web \
                --account-name ${{ parameters.terraformStorageAccountName }} \
                --https-only \
                --permissions dlrw \
                --expiry $end \
                -otsv`

            # Init terraform env
            terraform init \
            -backend-config="access_key=$sas" \
            -backend-config="storage_account_name=${{ parameters['storageAccountName'] }}" \
            -input=false 

            # Fail on errors, output every command and result to the log
            set -e -x

            # Generate a Terraform plan
            terraform plan \
            -var environment="${{ parameters.environment }}" \
            -out=${{ parameters.environment }}.tfplan \
            -input=false 

            # Apply Terraform Template
            terraform apply ${{ parameters.environment }}.tfplan

[tombuildsstuff]

hi @jlorich

Thanks for opening this issue.

When running in automation we require using either a Service Principal or Managed Service Identity - unfortunately we do not support using the Azure CLI (for example when authenticated to the Azure CLI as a Service Principal the files saved on disk by the Azure CLI don't contain all of the information required - as is the case here).

As such would you be able to take a look and see if switching to a Service Principal/MSI works for you? Since this is a question regarding Terraform Configuration rather than a bug in the Azure Provider I'm going to close this issue - but please let me know if that doesn't solve your issue and we'll take another look

Thanks!

[sikemullivan]

Getting the same issue on DevOps Release Task. Why does the script below work on windows, but fail on the ubuntu release agent?

az login --service-principal --username <tenant_id> --tenant <tenant_id> --password "mycert.pem"
terraform init
terraform plan
terraform apply -auto-approve

[tombuildsstuff]

@sikemullivan unfortunately we don't support authenticating as a Service Principal when using the Azure CLI - as the Azure CLI doesn't contain all the information we require when authenticated as a Service Principal.

Instead we support authenticating as a Service Principal using the natively supported Service Principal authentication method.

Thanks!

[sikemullivan]

Yea, was just a bit thrown out of place when it worked local but not on the server. I have it working now.

[jlorich]

@tombuildsstuff I'm curious, why? Generating and managing a service principal is annoying and should be unnecessary when Azure DevOps will manage the whole thing for you with the CLI task. I'd much rather not recommend people keep keys around, even if stored securely. The mere possession of them adds unnecessary risk.

@sikemullivan For the near term you can do this:

    - task: AzureCLI@1
      displayName: Terraform Deploy
      inputs:
        azureSubscription: $(azureSubscription)
        scriptLocation: inlineScript
        workingDirectory: $(System.DefaultWorkingDirectory)/terraform/
        addSpnToEnvironment: true
        inlineScript: |
            export ARM_CLIENT_ID=$servicePrincipalId
            export ARM_CLIENT_SECRET=$servicePrincipalKey
            export ARM_SUBSCRIPTION_ID=$(az account show --query id | xargs)
            export ARM_TENANT_ID=$(az account show --query tenantId | xargs)

The export pulls the SP info from the CLi task and exports it for Terraform to read. Ideally these lines should not be needed.

[jlorich]

Tagging @cwiederspan as we run into this a lot with customers. There is currently no easy and clean way to use terraform in CI without juggling keys. There's no officially supported tasks (the community ones all are varying levels of okay) and there's these hoops to jump through to get things to work via command line. It's not a smooth experience.

[tombuildsstuff]

@sikemullivan

Yea, was just a bit thrown out of place when it worked local but not on the server. I have it working now.

Glad to hear this is now working. The next version of the Azure Provider will contain a more helpful error message when attempting to authenticate with the Azure CLI using Service Principal; and suggesting instead using the alternate authentication method - which hopefully should help others diagnose this in the future 👍

[tombuildsstuff]

@jlorich

@tombuildsstuff I'm curious, why? Generating and managing a service principal is annoying and should be unnecessary when Azure DevOps will manage the whole thing for you with the CLI task. I'd much rather not recommend people keep keys around, even if stored securely. The mere possession of them adds unnecessary risk.

Unfortunately the Azure CLI doesn't contain the same information when authenticated as a Service Principal as when authenticated as a User; thus unfortunately we'd be unable to provide a consistent experience here. If you're running Terraform in a CI pipeline we recommend using either a Managed Service Identity (ideally) or a Service Principal (using either a Client Certificate or a Client Secret).

As mentioned above the next version of the AzureRM Provider will expose a more helpful error message when attempting to use the Azure CLI to authenticate when logged in as a Service Principal to make this clearer.

Thanks!

[ghost]

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 👉 hashibot-feedback@hashicorp.com. Thanks!