This is the 8th part of my Key Vault series - This time it has come to Azure DevOps. At Umbraco we've moved all of our build and release pipelines into Azure DevOps, this also forced us to look at how to get secrets from Key Vault, in order to do deployments and config transforms during pipeline executions.

When in Azure DevOps, use the Azure Key Vault Task

The Azure DevOps interface keeps evolving, and of this writing the build pipelines are in yaml, while the release pipelines are still in a "UI drag & drop"-kinda interface, so eventhough the task to implement is the same, it will look and feel a bit different.

Build pipelines

The objective is to add a task of type Azure Key Vault - this task will read all secrets (or the specified ones) into system variables that can then be used through the build pipeline.

In the build pipelines, everything is handled via yaml. Adding tasks can be done either by their wizard or just by typing the informations needed. i.e. in my pipeline I get access to the task by adding this task definition:

- task: [email protected]
  inputs:
   azureSubscription: 'Mikkel - Visual Studio Enterprise – MPN (8bxcxx2x-e0x2-4ex3-9axc-bx5x6x5x1xxx)'
   KeyVaultName: 'KeyVaultSeriesKeys'
   SecretsFilter: '*'
By just typing the task manually you need to already have setup a Service connection between your Azure Devops project and your Azure Subscription - But if you add the task via the guided experience, you will be enabled to add the connection through the UI, which is alot easier.
Once the task has been added, all the secrets in from the Key Vault instance will be available as variables, that can be used in the following steps. I.e. a simple usage is in a script task like this:
- script: echo Hello, world! $(MySuperSecretKey)
  displayName: 'Run a one-line script'
The above task will output "Hello, world! ***" - the *** is the value from Azure Key Vault, bu as Azure DevOps wont display secrets its just replaced with ***. 
This also means that now you can use the variables to build your software. i.e. adding credentials to access private nuget feeds for restoring solutions, access to container registries or blob storage, where files is needed for your build. 
One of the most normal usecases would be to do transforms for config files, so they are updated in the build output and ready for deployment. This could be web.config files or the yaml files being used for Docker and Kubernetes.

Release pipelines

Once you have build your solution, it needs to be deployed to somewhere. Luckily the same task we used in the build pipelines is also available in the Release part of Azure DevOps: 
The task can used to deploy your software to stuff like:
  • NuGet
  • Octopus Deploy
  • a Container Registry (like ACR)
  • a Docker Engine
  • a Kubernetes Cluster (like AKS)
  • a Webapp via MSDeploy
  • or simply copy them to a blob location

The credentials needed to access the destination, should all be stored in the Azure Key Vault instance, and then used when deploying. This should ensure that you only manage your secrets from one place, and that noone actually gets to see them, except the ones in charge of maintaining your Azure Key Vault.

Azure Key Vault series index

  1. Intro
  2. Creating and accessing Azure Key Vault
  3. Get secrets from Azure Key Vault in your app
  4. Client Id/ApplicationId vs Certificate based access
  5. Using Key Vault from an Azure Web App
  6. Using Key Vault with Azure Functions
  7. Using Key Vault from a Virtual Server
  8. Using Azure Key Vault in Azure DevOps (you are reading it)
  9. Using Key Vault in an Umbraco site
  10. Using Key Vault in an Umbraco Cloud site

References