Azure Managed Identity vs Key Vault secrets — CI/CD Automation — Practical Guide (Apr 23, 2026)
Azure Managed Identity vs Key Vault secrets — CI/CD Automation
Level: Intermediate
Date: April 2026
When automating Continuous Integration and Continuous Deployment (CI/CD) pipelines on Azure, securely managing credentials and secrets is critical. Two common methods for authentication and secret management are Azure Managed Identity and Azure Key Vault secrets. Understanding their differences, use cases, and integration patterns can save you time and reduce security risks.
Prerequisites
- Azure subscription with owner or contributor access
- Azure DevOps, GitHub Actions, or other CI/CD platform configured
- Azure CLI (version 2.50 or later recommended for latest features)
- Basic familiarity with Azure Active Directory (AAD), Azure Key Vault, and Azure Managed Identities
- .NET, PowerShell, or any SDK capable of authenticating to Azure resources (optional for automation scripting)
Overview: Managed Identity vs Key Vault Secrets
Both Managed Identities and Key Vault secrets enable applications and automation agents to access sensitive information without embedding credentials in code or pipeline config files.
Azure Managed Identity is a feature of Azure Active Directory that allows Azure resources to authenticate securely to other Azure services. No credential management is required because the identity is managed by Azure.
Azure Key Vault secrets</strong are key-value pairs stored in an encrypted vault designed to centralise secrets management. Access is controlled via policies, and retrieval typically requires a service principal or managed identity to authenticate.
When to choose Managed Identity vs Key Vault secrets
- Choose Managed Identity for authentication scenarios where your pipeline runs within Azure (e.g., Azure DevOps agents, Azure Functions, Azure VM agents) that can natively obtain tokens without explicit secrets.
- Choose Key Vault secrets</strong for storing and managing credentials that cannot be replaced by Managed Identities, such as database connection strings, 3rd-party API keys, or legacy apps consuming secrets directly.
- Many pipelines benefit from combining both: use Managed Identity to securely retrieve Key Vault secrets dynamically during runtime.
Hands-on steps
1. Enable and use Managed Identity in your pipeline
Assuming you have a pipeline agent running inside an Azure resource that supports managed identity (e.g., Azure VM, Azure Container Instance, Azure DevOps hosted agent with workload identity), follow these steps:
# Assign a managed identity to the Azure resource (example: VM)
az vm identity assign --name myVM --resource-group myResourceGroup
# Grant the identity access to Key Vault (read secrets)
az keyvault set-policy --name myKeyVault --object-id <identity-principal-id> --secret-permissions get list
In your CI/CD pipeline script, use Azure SDKs or CLI to acquire tokens via Managed Identity automatically. For example, using Azure CLI:
# Get an access token for Azure Key Vault using managed identity
az account get-access-token --resource https://vault.azure.net
# Use the token to fetch secrets using az keyvault or HTTP API
az keyvault secret show --vault-name myKeyVault --name mySecret
2. Store and access Key Vault secrets directly in your pipeline
If your pipeline runs outside Azure or your agent cannot use Managed Identity, you can use a service principal or personal access token to authenticate.
# Create a service principal with secret (rotate periodically)
az ad sp create-for-rbac --name "my-sp" --role Reader
# Store its tenantId, appId, and secret in pipeline variables/secrets securely
# Assign Key Vault access policy to the service principal
az keyvault set-policy --name myKeyVault --spn <appId> --secret-permissions get
# Authenticate in pipeline script
az login --service-principal -u <appId> -p <clientSecret> --tenant <tenantId>
# Retrieve secret
az keyvault secret show --vault-name myKeyVault --name mySecret
Alternatively, in Azure DevOps, use the built-in Key Vault task to link secrets as pipeline variables securely.
Common pitfalls
- Misconfigured access policies: Both Managed Identity and service principals need explicit Key Vault policies. Forgetting permissions leads to access denied errors.
- Expired credentials: Service principal secrets require manual rotation; if expired, pipelines break. Managed Identities, in contrast, are rotated automatically by Azure.
- Assuming Managed Identity availability: Some hosted pipeline agents (e.g., GitHub hosted runners) do not support Managed Identity without additional setup (workload identity federation, a preview feature as of 2026).
- Pipeline secrets leakage: When fetching secrets from Key Vault, output must be masked correctly in logs to prevent leakage.
- Network restrictions: Key Vault configured with virtual network or firewall rules can prevent access unless agent IP/range is whitelisted.
Validation
After configuration:
- Check that Managed Identity or service principal can authenticate by running CLI commands on the pipeline agent.
- Verify permissions by attempting to read (and if needed, write) secrets from Key Vault.
- Review pipeline logs for authentication errors or secret retrieval failures.
- Inspect Azure Key Vault access logs in Azure Monitor for successful and failed access attempts.
Checklist / TL;DR
- Use Managed Identity when possible as it eliminates managing secrets manually.
- Grant minimum privileges: Only grant ‘get’ or ‘list’ on secrets needed for pipeline steps.
- Apply network policies: Ensure pipeline agents have allowed access to Key Vault endpoints.
- Set up secret rotation: Prefer Managed Identity to avoid this; otherwise automate rotation of service principal secrets.
- Mask all secrets: In pipeline outputs and logging.
- Implement monitoring: Use Azure Monitor diagnostics for audit trails.