Gettings this stubborn error during

pulumi up

from my Azure Pipeline:

Diagnostics:
  azure:core:ResourceGroup (licensing-dev-rg):
    error: Error building account: Error getting authenticated object ID: Error listing Service Principals: autorest.DetailedError{Original:adal.tokenRefreshError{message:"adal: Refresh request failed. Status Code = '401'. Response body: {\"error\":\"invalid_client\",\"error_description\":\"AADSTS7000215: Invalid client secret is provided.\\r\\nTrace ID: d537fece-7902-4d0b-8696-debcc5b85900\\r\\nCorrelation ID: 62a70c31-1c5d-4de2-9503-b6c6ba7f555c\\r\\nTimestamp: 2020-01-12 20:48:44Z\",\"error_codes\":[7000215],\"timestamp\":\"2020-01-12 20:48:44Z\",\"trace_id\":\"d537fece-7902-4d0b-8696-debcc5b85900\",\"correlation_id\":\"62a70c31-1c5d-4de2-9503-b6c6ba7f555c\",\"error_uri\":\"<https://login.microsoftonline.com/error?code=7000215>\"}", resp:(*http.Response)(0xc00014c120)}, PackageType:"azure.BearerAuthorizer", Method:"WithAuthorization", StatusCode:401, Message:"Failed to refresh the Token for request to <https://graph.windows.net/***/servicePrincipals?%24filter=appId+eq+%27***%27&api-version=1.6>", ServiceError:[]uint8(nil), Response:(*http.Response)(0xc00014c120)}

Using the Pulumi Task Extension for Azure Pipeline. My task YAML looks like this:

- task: Pulumi@1
    displayName: Create/update Azure resources
    inputs:
      azureSubscription: 'IDeliverable Azure Subscription'
      command: 'up'
      args: '--skip-preview --yes'
      cwd: 'infra/'
      stack: 'dev'
    env:
      PULUMI_ACCESS_TOKEN: $(PulumiAccessToken)
  - script: |
      echo "##vso[task.setvariable variable=appName;isOutput=true]$(pulumi stack output appName)"
    displayName: Set stack outputs as variables
    name: stackVariables

The service connection

IDeliverable Azure Subscription

exists and validates fine. The same service connection is also used successfully from other non-Pulumi tasks. I triple-checked the client secrets, even generated new ones and updated and verified, but still Pulumi fails with this. Any ideas?

@clever-sunset-76585 might be able to help

Interestingly, it works if I manually map in the

ARM_*

variables, like so:

- task: Pulumi@1
  displayName: Create/update Azure resources
  inputs:
    azureSubscription: IDeliverable Azure Subscription
    command: up
    args: --skip-preview --yes
    cwd: infra/
    stack: dev
  env:
    PULUMI_ACCESS_TOKEN: $(PulumiAccessToken)
    # The below should not be necessary since this task is using a service connection, but it does not seem able to correctly get the client secret from the connection, so for now this is the workaround.
    ARM_CLIENT_SECRET: $(AzureClientSecret)
    ARM_SUBSCRIPTION_ID: $(AzureSubscriptionId)
    ARM_CLIENT_ID: $(AzureClientId)
    ARM_TENANT_ID: $(AzureTenantId)
- script: |
    echo "##vso[task.setvariable variable=appName;isOutput=true]$(pulumi stack output appName)"
  displayName: Set stack outputs as variables
  name: stackVariables

Hi Daniel, I have a couple of questions for you. - How did you create your service connection? Sometimes this error could be because of an expired client secret tied to the service principal of your service connection. - Does this service connection work with other tasks? Lastly, it is possible that there is a subtle difference in how your service connection was created, that the task isn't able to get credentials from it. (Though I doubt that is the case.)

@clever-sunset-76585 I now understand what was going on. It turns out the “edit service connection” dialog in DevOps has a major bug.

Ohh that is a bad problem indeed. Glad you found it, though. Also I am curious. Could you not let the service connection create a new service principal automatically in your Azure Subscription?

@clever-sunset-76585 Yes, that’s what happens when you create a new service connection or update an existing with the “simplified” dialog.

And we need to maintain several different client secrets for the same service principal, for different contexts, different expiration etc, so we need to name them better to tell them apart.

Yep. I see what you mean.