Error building AzureRM Client: Authenticating using the Azure CLI is only supported as a User (not a Service Principal)

[dokuboyejo]

The following have been set, and works when a preview is performed. It however fails each time a refresh (pulumi refresh) or update (pulumi update) action is invoked when trying to deploy through jenkins-ci using service principal. Any ideas what else needs to be done?

azure:clientId 
azure:clientSecret
azure:tenantId 
azure:subscriptionId
``

as well as

ARM_CLIENT_ID ARM_SUBSCRIPTION_ID ARM_CLIENT_SECRET ARM_TENANT_ID

[dokuboyejo]

Anyone with some guidance on this?

[dokuboyejo]

Preview failed: Error building AzureRM Client: Authenticating using the Azure CLI is only supported as a User (not a Service Principal).", " ", " To authenticate to Azure using a Service Principal, you can use the separate 'Authenticate using a Service Principal'", " auth method - instructions for which can be found here: https://www.terraform.io/docs/providers/azurerm/guides/service_principal_client_secret.html", " ", " Alternatively you can authenticate using the Azure CLI by using a User Account.

[alexbechmann]

@dokuboyejo

We've been successful by setting the following environment variables: (Notice the ARM + AZURE prefixed variables).

ARM_CLIENT_ID ARM_CLIENT_SECRET ARM_TENANT_ID AZURE_CLIENT_ID AZURE_CLIENT_SECRET AZURE_TENANT_ID ARM_SUBSCRIPTION_ID

[shapeofarchitect]

Can you elaborate how ? Did you mean that I have to set ARM + AZURE both or one of them ? @alexbechmann @dokuboyejo

[alexbechmann]

@shapeofarchitect for me i set both, all the ones from my previous message.

[shapeofarchitect]

Thank you . I was able to solve this just with ARM_* environment variables only , my initial problem occurred due to protected flag set on variable definition in gitlab which only applies to the protected branches. so once I removed that , it worked as expected.

[keithharvey]

I think it depends on which provider you're using? azure.keyvault.getSecret seems to use the AZURE_ prefix and theoretically azure-native would use the ARM..

[didaskein]

I'm running terraform in WSL on windows, if you create an init.sh file with the code below :

    export ARM_CLIENT_ID="__spn_client_id__"
    export ARM_CLIENT_SECRET="__spn_client_secret__"
    export ARM_TENANT_ID="__tenant_id__"
    export ARM_SUBSCRIPTION_ID="__subscription_id__"

when you want to run it : $ . ./init.sh
don"t forget the . before the name of the file.

To check that you set the environnement variable you can run the command : $ env | grep ARM You should see the variables.

[kxs-sindrakumar]

@alexbechmann for Azure and ARM, are they the same values? or are they different?

[alexbechmann]

@kxs-sindrakumar I think we used the same values, I don't know if this is needed any more or not though :)

[haidangwa]

I recently ran into this problem with terraform azurerm provider 3.8.0. My pipeline kept failing in gitlab-ci even though I was logging into my azure subscription using az login --service-principal ... as the documentation calls. It resolved for me once I exported the ARM_* environment variables that @didaskein mentioned. The values are exactly the same as what I used in my az login command. This seems like a bug in the azurerm provider in that it shouldn't rely on the env vars if my session is already logged in via cli.

[mikhailshilkov]

Possibly related: https://github.com/hashicorp/terraform-provider-azurerm/issues/22034

[davidmnoll]

azure-native:containerregistry:Registry (fosRegistry):
      error: Authenticating using the Azure CLI is only supported as a User (not a Service Principal)

I've been running into this issue intermittently. I ran the following workflow.

        # uses: azure/login@v1
        # with:
        #   # client-id: ${{ secrets.AZURE_CLIENT_ID }}
        #   # tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        #   # # subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
        #   # allow-no-subscriptions: true
        #   # enable-AzPSSession: true
        #   creds: ${{ secrets.AZURE_CREDENTIALS }}
        run: az login --service-principal -u ${{ secrets.AZURE_CLIENT_ID }} -p ${{ secrets.AZURE_CLIENT_SECRET }} --tenant ${{ secrets.AZURE_TENANT_ID }}
      - uses: pulumi/[email protected]
        with:
          command: refresh
          work-dir: pulumi
          stack-name: my-org/my-stack
          # upsert: true
        env:
          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
      - uses: pulumi/[email protected]
        with:
          command: up
          work-dir: pulumi
          stack-name: my-org/my-stack
          # upsert: true
        env:
          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
          # ARM_USE_OIDC: "true"
          ARM_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
          ARM_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
          # ARM_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
          ARM_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
          # ARM_LOCATION_NAME: "East US 2"

The first time it ran, it failed with this error:

error: 1 error occurred:
      	* A Subscription ID must be configured when authenticating as a Service Principal using a Client Secret.

Then I went back and reran the workflow and got the error at the top about logging in with a service principal

This has happened a few times now while I'm trying to set up this github action. Why would this be happening intermittently? It's almost like there's a token whic works it is first received, but after that it it doesn't work until it expires again? Just a guess. Seems like it may be a bug in the provider though.

Is logging in with a service principal not the standard way to use this?