Azure Key Vault vs. Pipeline Variables

By Anatoly Mironov

Using Azure Key Vault in a Pipeline is cool, but it is less secure.

The Key Vault setup

Have you tried the Key Vault Step in an Azure DevOps Pipeline? If you haven’t, please follow these awesome guides:

The steps described in these guides are easy, but that effort made me think about the first pair of pros and cons.

A pipeline variable is faster to configure

A variable in a pipeline takes zero time to set up. Also, A secret variable remains as a secret, since no one can read it in plain text. To configure the Key Vault way of getting secrets requires admin time. Unless you have Admin rights in your Azure Active Directory and your Azure Subscription, you might need to request and argument for one or more of the following:

  • A service principal (an App registration) with a secret.
  • An Azure Key Vault (and maybe a resource group) with an Access Policy for the service principal
  • A service connection in your Azure DevOps Project

Of course, most of it is one-time-job. But still, in many organizations it will require good preparation. The pros for an Azure Key Vault secrets in a pipeline is that

  • Admins can manage the secrets centrally from Azure
  • It is easier to audit the Key Vault Access.
  • Set it up once and let Azure DevOps people use it and re-use it in many pipelines, but still you need to set up a new Service Connection in every Azure DevOps Project

The fact that it is easier to reuse lets me think of my second pair of pros and cons.

A pipeline secret variable is more secure

Let’s say you need a password to a service account that will upload something important, e.g. an account that will upload a new SPFx package to the SharePoint App Catalog.

Doing it the pipeline variable way means that it remains as a secret on that particular release pipeline. Only release administrators of that project can alter the pipeline steps. No one else.

A tip for productivity: Use Group Variables to share the secrets within a project in Azure DevOps.

Doing it the Key Vault way, means that you must watch out on every part of that chain:

  • Users who have access to the Key Vault in Azure.
  • Service Principal that can read the secrets through access policy. Who has access to the secret?
  • Service Connection in an Azure DevOps Project. Who can use this Service Connection - to add and modify release pipelines? By default, all Release Administrators can do that. To do it more secure, you need to limit the count of Release Administrators. But it means less flexibility in a team and more admin effort for the allowed Release Administrators.

Also, the service principal used for getting the secrets and in the service connection, should not be reused across projects in Azure DevOps. Dedicated Service Principals will make it more secure because misuse can be more easily discovered and stopped - and thats on a project level, not for all service connections.

Summary

In flat small organizations, using a Key Vault for using secrets in Azure DevOps Pipelines is great, it saves you time. But it is less secure, and requires time and effort for an appropriate security.

Comments from Wordpress.com

Aleksandr Sapozhkov - Dec 5, 2019

On the other hand, it might be not totally correct to say that the only place to protect is pipeline variables. In reality, the chain will be: 1. Some secrets storage 2. A person/client device that is copying pasting from secrets storage to pipeline 3. Pipeline itself Or maybe we don’t need to save these secrets anywhere else but pipeline?

Anatoly Mironov - Dec 5, 2019

Thank you for nuancing this. Of course, pipelines do not garantee 100% security, but it more secure, in my opinion. There are many cases where storing secrets can only be just in pipelines.

Anatoly Mironov - Dec 5, 2019

Thank you for your feedback. Really good points, too!

Dennis Gaida - Dec 4, 2019

Very good points and I agree with everything you said. Additionally I would like to add that AKV also doesn’t have per-key-permissions. A problem arises with larger projects where you might need to manage multiple secrets (connection string to DB1, connection string to DB2, password for LOBSYSTEM1) and all those secrets are typically not managed by one person. You could have multiple AKV, but that would be a hassle to manage. Per-key-permissions are in preview now so we’ll be better off soon, but I guess your global admin can see everything problem doesn’t go away.

Git Merge develop to main in an Azure DevOps Release | CHUVASH.eu - Apr 5, 2021

[…] and a Pipeline. Well, due to reasoning described in my other blog post, we still run Releases: Azure Key Vault vs. Pipeline Variables. But Pipelines should work, […]