Running Azure CLI script from release pipeline using Service Principal - invalid_client

user_262892 0
Viewed 4619

I have an Azure CLI script which runs perfectly well in the Cloud Shell but I run into trouble when I try to include it in a devops release pipeline. For debugging purposes I've reduced the script to simply signing-in as a Service Principal and then retrieving the version...

az login --service-principal -u http://[Service Principal name] -p [Service Principal password] --tenant [Service Principal tenant GUID]
az --version

...but it still incurs the same error.

Here are the properties of my Azure CLI task:

Script Type: Shell
Script Location: Inline script
Inline Script: [as above]
Script Arguments:
Access service principal details in script: false
Use global Azure CLI configuration: false
Working Directory:
Fail on Standard Error: false
Enabled: true
Continue on error: false*
Environment Variables:

And the error is:

2020-06-15T12:46:39.8710944Z ##[error]Error Code: [1]
2020-06-15T12:46:39.8724737Z ##[error]Error: Azure login failed
2020-06-15T12:46:39.8728448Z ##[error]Script failed with error: Get Token request returned http error: 401 and server response: {"error":"invalid_client","error_description":"AADSTS7000222: The provided client secret keys are expired. Visit the Azure Portal to create new keys for your app, or consider using certificate credentials for added security: https://docs.microsoft.com/azure/active-directory/develop/active-directory-certificate-credentials
Trace ID: d0f42793-739e-4ce9-9118-5049086aa800
Correlation ID: 2ad50471-9c2a-4c02-a4d0-189efad2f0c8
Timestamp: 2020-06-15 12:46:39Z","error_codes":[7000222],"timestamp":"2020-06-15 12:46:39Z","trace_id":"d0f42793-739e-4ce9-9118-5049086aa800","correlation_id":"2ad50471-9c2a-4c02-a4d0-189efad2f0c8","error_uri":"https://login.microsoftonline.com/error?code=7000222"}

I was able to authenticate as this Service Principal using the Azure Cloud Shell so I'm puzzled as to why I apparently can't do the same from within the release pipeline.

* I have tried with Continue on error: true and although the task completes the same error appears in the output.

azure-pipelines-release-pipeline azure-cli devops azure
2 Answers

To use the service principal in Azure CLI, no need to login manually.

For the correct way, please follow the steps below.

1.From the error message, the client secret(i.e. client key) of your service principal is expired. So you need to check it first, navigate to the azure portal -> Azure Active Directory -> App registrations -> All applications -> find the AD App related to your service principal -> Certificates & secrets -> check if the secret is expired. If it is expired, just click New client secret to create a new one and save the value.

enter image description here

2.In devops, navigate to the Project Settings -> Service connections -> New service connection -> Azure Resource Manager -> Service principal (manual).

enter image description here

enter image description here

enter image description here

Then fix the options with your service principal, you can get the values from your AD App in App registration page. The Service Principal Id is the Application (client) ID, the Service principal key is the client secret.

enter image description here

The Subscription Id and Subscription Name is which you want to use Azure CLI to access, you could find them in azure portal.

enter image description here

After input the values -> Verify -> Verify and save.

enter image description here

3.In your Azure CLI task -> Azure Resource Manager connection -> select the service connection in step 2. In my sample, I test to get a web app in my subscription with az webapp show --name xxxx --resource-group xxxx(Note: no need to use az login manually, it will login with the service principal which was configured in the service connection automatically).

enter image description here

Then run it and check the result, it works fine.

enter image description here

user_94556590

I think this is very similar to the problem i faced earlier, it happens when there is a special character in the client secret.

One workaround is to go to the Azure portal and keep generating new secrets until you get one that does not have special characters in it.

https://github.com/ansible/ansible/issues/54914

user_17494030
Related