What happens when you link an Azure DevOps Variable Group to an Azure Key Vault?

Background

It is a really useful feature that you can expose Key Vault stored secrets as Azure DevOps pipeline variables via a variable group, but what happens when you do this? And what can you do if you try to expose too many variables?

I was recently working on a system where there was an increasing number of Key Vault secrets that were being exposed as variables via a variable group. This was working fine, until I started getting warnings in the following form on Windows based Azure DevOps agents:

Environment variable 'VSTS_SECRET_VARIABLES' exceeds the maximum supported length. Environment variable length: 32993 , Maximum supported length: 32766

It was flagged as a warning, but in reality the pipeline failed as none of the secrets were being exposed as variables.

Analysis

When you link a variable group to a Key Vault, the secrets are exposed as environment variables. This is automatically done by the pipeline agent running the AzureKeyVault@1 task (interestingly not the newer AzureKeyVault@2 task) prior to any other steps in the containing job. This task takes parameters for the Key Vault name and a comma separated list based filter for the secrets to expose. Both of these are derived from the settings of the variable group.

Workarounds

The simplest workarounds are to either:

• Switch to a Linux based agent which has a much higher limit on the length of environment variables. A move that is not always possible depending on the other tasks in the job.
• Or to reduce the number of secrets exposed as variables. This can be done by either removing secrets from the Key Vault or by removing secret mapping within the variable group. A valid solution, but one that requires manual management.

This got me thinking, is there another way to build the secret filter list so it is more flexible than a manually managed comma separated list?

The answer is yes, you can use a PowerShell script to build the list of secrets to expose and then call the AzureKeyVault task directly.

Instead of exposing the key Vault secrets via the variable group, you could use the following tasks.

• A PowerShell script is used to convert a wildcard based filter into a comma separated list of secrets(this does assume you have a consistent secret naming convention)
• Then, use the same AzureKeyVault task, to expose the secrets as environment variables.