Access Key Vault from Azure DevOps Pipeline (YAML & Classic)

Quick answer: Azure DevOps pipelines can retrieve secrets from Azure Key Vault using the AzureKeyVault@2 task or an Azure DevOps variable group linked to Key Vault. The pipeline authenticates through an Azure Resource Manager service connection, while the service connection identity must have permission to read the required secrets. Microsoft recommends workload identity federation or managed identities instead of long-lived client secrets where supported.

Prerequisites:
1. An Azure DevOps project and pipeline.
2. An Azure Key Vault containing the required secrets.
3. An Azure Resource Manager service connection that can authenticate to Azure.
4. Permission for the service connection identity to read Key Vault secrets.

How Azure DevOps Accesses Key Vault

The identity used by the Azure Resource Manager service connection is the identity that needs access to Key Vault. Do not assume that every Azure DevOps project has a single service principal. Check the specific service connection used by your pipeline and grant that identity the required Key Vault permissions.

Create or Check the Azure DevOps Service Connection

In Azure DevOps, go to Project settings → Service connections and identify the Azure Resource Manager service connection that your pipeline will use.

For new connections, prefer workload identity federation or a managed identity where supported. Microsoft recommends workload identity federation over service connections that use manually managed client secrets because it avoids storing and rotating long-lived credentials.

The screenshot below shows the Microsoft Entra application registration associated with the service principal. Use it to identify the application when verifying which identity is behind the Azure DevOps service connection.

Grant the Service Connection Access to Key Vault

First check the Key Vault permission model under Settings → Access configuration. The steps differ depending on whether the vault uses Azure RBAC or the legacy Access Policies model.

Azure RBAC

1. Open the Key Vault in the Azure portal.
2. Select Access control (IAM).
3. Select Add → Add role assignment.
4. For a pipeline that only needs to read secrets, assign the Key Vault Secrets User role to the identity used by the service connection.
5. Complete the role assignment.

Access Policies

1. Open the Key Vault and select Access policies.
2. Create a policy with the required secret permissions. For read-only pipeline access, use Get and List.
3. Select the identity used by the Azure DevOps service connection.
4. Review and create the policy.

Microsoft’s current Azure Pipelines guidance documents both managed identity and service principal authentication patterns for Azure Resource Manager service connections.

Access Key Vault Secrets in a YAML Pipeline

Use AzureKeyVault@2 to download selected secrets from Key Vault into the pipeline. Microsoft currently documents version 2 of this task.

steps:
- task: AzureKeyVault@2
  displayName: Get secrets from Azure Key Vault
  inputs:
    azureSubscription: 'service-connection-name'
    KeyVaultName: 'key-vault-name'
    SecretsFilter: 'secret1,secret2'
    RunAsPreJob: false

After the task runs, the downloaded secrets are available as pipeline variables. Map secrets to environment variables when passing them to scripts or applications, and never print their values to pipeline logs.

Link an Azure DevOps Variable Group to Key Vault

If several pipelines need the same Key Vault secrets, you can link an Azure DevOps variable group to Key Vault instead of adding the task to every YAML file. Microsoft supports this through Pipelines → Library → Variable groups.

1. Go to Pipelines → Library and select + Variable group.
2. Enable Link secrets from an Azure Key Vault as variables.
3. Select the Azure service connection.
4. Select the Key Vault.
5. Select the secrets to expose to the variable group.
6. Save the variable group and authorize the pipeline when prompted.

variables:
- group: 'my-keyvault-variable-group'

Use a variable group when centralized secret management is useful across multiple pipelines. For pipeline-specific secrets, the AzureKeyVault@2 task can be simpler.

Classic Pipelines

For a classic Azure DevOps pipeline, add the Azure Key Vault task to the agent job and select the Azure Resource Manager service connection and Key Vault. The same identity and Key Vault permission requirements apply.

Troubleshooting

403 / Forbidden
Check that the identity behind the selected service connection has permission to read secrets from the Key Vault. For RBAC, verify the appropriate Key Vault role; for Access Policies, verify the required secret permissions.

Secret not found
Check the exact secret name and the SecretsFilter value. If multiple secrets are requested, provide their names as a comma-separated list.

Variable group cannot access Key Vault
Verify that the selected service connection is authorized and that it has the required Key Vault permissions. For RBAC-enabled vaults, check the role assignment on the Key Vault.

Private Key Vault cannot be reached
A private Key Vault requires additional network configuration. Microsoft provides a separate procedure for accessing private Key Vaults from Azure Pipelines.

Pro tips:
1. Prefer workload identity federation or managed identities over long-lived service principal secrets.
2. Grant the pipeline identity only the Key Vault permissions it needs.
3. Never hard-code secrets in azure-pipelines.yml or echo them to logs.
4. Use a variable group when the same Key Vault secrets are shared across multiple pipelines.

See more

Visual Studio Marketplace

SSIS Catalog Migration Wizard

Extend Visual Studio with an easy way to migrate SSIS Catalog projects.

Get it from Visual Studio Marketplace

Kunal Rathi

With over 15 years of experience in data engineering and analytics, I've assisted countless clients in gaining valuable insights from their data. As a dedicated supporter of Data, Cloud and DevOps, I'm excited to connect with individuals who share my passion for this field. If my work resonates with you, we can talk and collaborate.