https://pulumi.com logo
Title
p

powerful-football-81694

01/12/2020, 8:54 PM
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?
t

tall-librarian-49374

01/12/2020, 8:59 PM
@clever-sunset-76585 might be able to help
p

powerful-football-81694

01/12/2020, 9:37 PM
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
But while a viable workaround, obviously this is not ideal since it kind of negates the point of the service connection and forces us to store these credentials as variables.
c

clever-sunset-76585

01/12/2020, 10:33 PM
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.)
p

powerful-football-81694

01/13/2020, 10:35 AM
@clever-sunset-76585 I now understand what was going on. It turns out the “edit service connection” dialog in DevOps has a major bug.
Manually updating the client secret has no effect! The new client secret is not persisted on the service connection, instead it’s saved with an empty client secret value.
You literally have to delete and create a new service connection in order to set a client secret.
As a result, I believe the service connection, even though it was validated, was saved without a client secret.
I should really report that to Microsoft...
c

clever-sunset-76585

01/13/2020, 3:26 PM
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?
p

powerful-football-81694

01/13/2020, 5:30 PM
@clever-sunset-76585 Yes, that’s what happens when you create a new service connection or update an existing with the “simplified” dialog.
Then it creates the client secret for you.
But then it creates a nameless one in Azure.
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.
That’s the kind of scenario that the “full” dialog is supposed to accommodate.
c

clever-sunset-76585

01/13/2020, 5:38 PM
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.