In this post I’ll demonstrate how you can configure your Azure DevOps pipeline to grab Secrets directly from an Azure Key Vault, rather than setting them within Azure DevOps Pipeline variables.  Additionally, i’ll demonstrate how to pass those secrets as parameters into a PowerShell task within a DevOps Pipeline. The PowerShell task will grab those secrets and will invoke an API call to obtain a bearer token for the Service Principal authentication against either Rest or GRAPH API calls.

Pre-requisites 

• Key Vault – This will be used to store our secret variables, including ClientID, ClientSecret and TenantID
• Service Principal – This will be used to run the Azure DevOps Pipeline (Azure Service Connector within Azure DevOps) and will be given Get & List permissions to the key vault secrets through a key vault access policy.
• Azure DevOps Project – My Pipeline that will run a PowerShell Task and will link a variable group to the pipeline that collects the secrets from the Azure key vault.

Create and Configure the Key Vault

I’ve written a basic PowerShell script that creates a new, or uses an existing , Azure Key Vault that will be used to store the following Service Principal details:

• ClientID (Application ID)
• ClientSecret (Application Secret)
• TenantID (Tenant ID of the subscription)

Once the Key Vault is created and the Service Principal credentials have been added to the vault as secrets, the script will then grant Get & List Secret permissions to the key vault for the Service Principal through an Access Policy. This in turn will allow the Service Principal in Azure DevOps to fetch the secrets at build time.

Once the script has completed, we can check the key vault access policies to ensure the service principal has Get & List secret permissions as shown in the following screenshot. 

Configuring the Service Principal in Azure DevOps

Within Azure DevOps I have configured my Service connection Azure-Build-ServicePrincipal as an existing Service Principal within Azure AD. For this you’ll need the following:

• Subscription ID
• Subscription Name
• Service Principal ID (Application Client ID)
• Service Principal Key (Application Secret that is provisioned at the time of the Service Principal creation)
• Tenant ID 

Once entered, click  “verify and save” to test the connection.

Configuring the Variable Group in Azure DevOps

Variable groups are used to store values that you want to control and make available across pipelines. As in our case, you can also use variable groups to store secrets and other values. https://docs.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=yaml

Within Azure DevOps select “Pipelines” -> “Library” -> “+ Variable Group”

Enter in the Variable group name: Azure Build Key Vault or something more aligned to your naming standards. 

Make sure “Allow access to all pipelines” is not selected, we only want our pipeline to be able to access our variable group. Under Azure Subscription select the service connection (Service Principal) and choose the Key Vault we created earlier. Under Variables click “Add” and select the following

• ClientID
• ClientSecret
• TenantID 

Configuring the Variable Group in Azure DevOps

The pipeline that I’ve previously created is called Azure Key Vault-CI. We want to link the variable group we created in the previous step to this pipeline. Under Variables select “variable groups” -> “Link variable group” as shown in the following screenshot. Select the variable group you created, in my case it is Azure Build Key, and click “Link”

You will now see that the key vault secrets have been linked to our pipeline.

Configuring the PowerShell task

The script that i’m running can be found below, as you can see there are three Parameters which will be passed in as script arguments at the PowerShell task build time. 

Below is the configuration of the PowerShell task. The important thing to highlight is the Script Arguments section. I’m passing in the secret variables from the Variable Group we created earlier as parameters.

Let’s take a look at the output.

As you can see from the output of the pipeline, we have successfully authenticated as the Service Principal and have a bearer token which can be used to invoke Rest or GRAPH API calls.

Hopefully this helps someone,

Sean