In this post, I am going to talk about how can you manage secrets in an Azure environment. In other words, managing secrets with Azure Key Vault and accessing them through DevOps pipeline.

Secrets and DevOps Pipeline

When you use Azure DevOps Pipelines to deploy aps, you would have pipelines to push your app into different environments. When its the development environment, you might not care if developers know the configuration values for that environment. However, when it comes to UAT or production, there are values that you don’t want developers to have access to. If secrets are stored in code in Azure Repos like in an appsettings.json file, then you’re creating a security risk. In such cases, you’ll want administrators to control the creation and configuration of those data. But developers still need to configure pipelines for build and deployment. And they need those values as part of configuration. So we need a way to store secrets and certificates securely and still be able to use them within an Azure pipeline without exposing their values.

What Kind of Secrets are Needed in Pipelines?

There would be cases where you need a certificate for use on an agent. There might be a need to override parameters in a JSON file used by infrastructure as code deployments. You might have connection strings to point your deployed apps at different databases depending on the environment. There are better ways to do that, particularly if you’re using Azure SQL Database. But if your database is MySQL or Oracle, then you’ll need to manage connection strings and passwords. There’s also storage account keys and shared access signatures to Azure Storage that you would normally store in config files for each environment. API keys for things like SendGrid or keys for cognitive services. I’m sure you can think of lots of your own examples, but the point is, the less people who have access to these values, the better.

Azure Key Vault

The best way to secure these information in Azure is to use Azure Key Vault. Azure Key Vault lets you store three kinds of information – keys, secrets, and certificates. Keys are asymmetric cryptographic keys, and we don’t actually retrieve those to use in pipelines, at least not with the built- in methods. Secrets are basically any string you want to store, so these are passwords, connection strings, and other values we need in DevOps pipelines. Certificates are just, well, certificates. Typically SSL or TLS-type certificates. We can retrieve those just like secrets. They come back to Azure Pipelines as strings.

Azure Key Vault and DevOps Pipeline

So how does an Azure pipeline access the key Vault? For authentication, you provide read-only access to Key Vault from the pipeline using the service principle of the service connection that is used to connect to Azure. An administrator can create the secret and the value. The developer creates and configures a pipeline. And the Pipeline can only read and use the values from Key Vault. This creates the separation between the people who manage the secrets from the people who use the secrets. Azure Key Vault has logging which will enable us to know who modified the secrets and when.

To Conclude…

There are two ways to retrieve the secrets into Azure Pipelines.
You can use the Key Vault Task within the pipeline. It connects to Azure using the service connection and downloads the secrets that you specify. Then it makes them available as environment variables in the pipeline.
The other way is to use variable groups. These allow you to have a central location that’s available to all pipelines or just certain pipelines that you authorize. It provides central management in your project for Key Vault connections. Variable groups still leverage this service connection for authentication. Currently, variable groups don’t support retrieving certificates though, so that might be a reason you need to stay with the Key Vault task.

In my next posts, I will show you how to use Key Vault Tasks and Variable Groups. Until then, stay safe.