Loading learning content...
Azure Key Vault takes a distinctively comprehensive approach to cloud security by unifying three critical security domains: secrets management, cryptographic key management, and certificate lifecycle management. This convergence reflects Microsoft's enterprise-focused philosophy—providing a single service that addresses the security needs of complex, hybrid organizations.
Unlike services that focus solely on secrets, Azure Key Vault positions itself as a complete cryptographic services platform. From storing database passwords to managing SSL certificates to providing encryption-as-a-service with hardware-backed keys, Key Vault serves as the cryptographic foundation for Azure workloads.
By the end of this page, you will understand Azure Key Vault's architecture, the differences between Standard and Premium tiers, how to leverage managed identities for secure access, certificate management capabilities, and integration patterns across Azure services. You'll be equipped to design Key Vault solutions for enterprise Azure deployments.
Azure Key Vault manages three distinct types of cryptographic objects, each with its own API surface and management capabilities:
1. Secrets — Arbitrary strings up to 25KB (API keys, passwords, connection strings)
2. Keys — Cryptographic keys for encryption, signing, and wrapping operations
3. Certificates — X.509 certificates with private key management and lifecycle automation
This unified approach allows organizations to consolidate their cryptographic infrastructure rather than managing separate systems for each function.
| Object Type | Use Cases | Size Limit | Operations |
|---|---|---|---|
| Secrets | Passwords, connection strings, API keys | 25KB | Get, Set, Delete, List, Backup, Restore |
| Keys | Encryption, signing, key wrapping | RSA 2048-4096, EC P-256/384/521 | Encrypt, Decrypt, Sign, Verify, Wrap, Unwrap |
| Certificates | TLS certificates, code signing | Based on key type | Import, Create, Renew, Policy management |
Vault Architecture:
Each Key Vault is a dedicated, isolated container with its own URI and access policies. Key Vaults are regional resources but can be replicated to paired regions for disaster recovery:
mycompany-prod-kv)https://{vault-name}.vault.azure.netCreate separate Key Vaults per environment and application tier: 'prod-payments-kv', 'prod-api-kv', 'staging-payments-kv'. This provides blast radius containment, simplified access policies, and clearer cost allocation. Don't create one vault for all secrets—isolation improves security posture.
Azure Key Vault offers two service tiers that differ primarily in how cryptographic keys are protected:
Standard Tier:
Premium Tier:
| Aspect | Standard | Premium |
|---|---|---|
| Key Protection | Software (FIPS 140-2 Level 1) | HSM (FIPS 140-2 Level 3) |
| Secret Storage | Software encryption | Software encryption |
| Certificate Storage | Software protection | HSM for private keys (optional) |
| Compliance | SOC, ISO, HIPAA | PCI DSS, FedRAMP High, HIPAA |
| Pricing (secrets) | $0.03/10K operations | $0.03/10K operations |
| Pricing (HSM keys) | N/A | $1/key/month + ops |
| Key Operations | $0.03/10K | $0.03/10K (software) / $0.15/10K (HSM) |
Choosing the Right Tier:
Even in Premium tier, secrets (text strings) are software-protected. HSM protection only applies to cryptographic keys. If you store a secret and then use an HSM key to add another layer of encryption, that's your application's responsibility. Key Vault's Premium tier doesn't automatically HSM-protect secrets.
Azure Key Vault historically offered Vault Access Policies and has since introduced Azure RBAC as the recommended access control model. Understanding both is essential as existing deployments may use either.
Azure RBAC (Role-Based Access Control) - Recommended:
Uses Azure's native RBAC system with built-in and custom roles assigned at the vault, secret, key, or certificate level.
1234567891011121314151617181920212223242526272829303132333435363738
# Create a Key Vault with RBAC authorizationaz keyvault create \ --name "prod-myapp-kv" \ --resource-group "rg-myapp" \ --location "eastus" \ --enable-rbac-authorization true \ --enable-soft-delete true \ --retention-days 90 \ --enable-purge-protection true # Assign built-in roles # Key Vault Administrator - Full managementaz role assignment create \ --role "Key Vault Administrator" \ --assignee "admin@company.com" \ --scope "/subscriptions/{sub}/resourceGroups/rg-myapp/providers/Microsoft.KeyVault/vaults/prod-myapp-kv" # Key Vault Secrets User - Read secrets onlyaz role assignment create \ --role "Key Vault Secrets User" \ --assignee "8a5c1234-5678-90ab-cdef-1234567890ab" \ # App's managed identity --scope "/subscriptions/{sub}/resourceGroups/rg-myapp/providers/Microsoft.KeyVault/vaults/prod-myapp-kv" # Key Vault Crypto User - Cryptographic operations onlyaz role assignment create \ --role "Key Vault Crypto User" \ --assignee "service-principal-id" \ --scope "/subscriptions/{sub}/resourceGroups/rg-myapp/providers/Microsoft.KeyVault/vaults/prod-myapp-kv/keys/encryption-key" # Built-in Key Vault roles:# - Key Vault Administrator: Full access to all objects# - Key Vault Reader: Read vault metadata only# - Key Vault Secrets Officer: Manage secrets (CRUD)# - Key Vault Secrets User: Read secrets# - Key Vault Crypto Officer: Manage keys (CRUD)# - Key Vault Crypto User: Perform crypto operations# - Key Vault Certificates Officer: Manage certificates (CRUD)RBAC vs Access Policies Comparison:
| Aspect | Vault Access Policies | Azure RBAC |
|---|---|---|
| Granularity | Vault level only | Vault, individual secret/key/cert level |
| Inheritance | None | Inherits from resource group/subscription |
| Condition Support | No | Yes (attribute-based conditions) |
| Azure Integration | Key Vault specific | Unified with all Azure resources |
| Audit | Key Vault logs only | Azure Activity Log + Key Vault logs |
| Maximum policies | 1024 per vault | Unlimited via role assignments |
For new deployments, always use Azure RBAC. For existing vaults with access policies, plan migration to RBAC for better granularity, unified management, and conditional access support. Note that you cannot use both models simultaneously on the same vault.
Managed identities represent Azure's solution to the credential bootstrapping problem—how do applications authenticate to Key Vault without having a secret to get secrets? Managed identities provide an automatically managed identity in Azure AD that applications can use to authenticate.
Types of Managed Identities:
12345678910111213141516171819202122232425262728293031323334
# Enable system-assigned managed identity on an App Serviceaz webapp identity assign \ --name "mywebapp" \ --resource-group "rg-myapp" # Output includes the principal ID# {# "principalId": "8a5c1234-5678-90ab-cdef-1234567890ab",# "tenantId": "12345678-1234-1234-1234-123456789012",# "type": "SystemAssigned"# } # Grant the managed identity access to Key Vaultaz role assignment create \ --role "Key Vault Secrets User" \ --assignee "8a5c1234-5678-90ab-cdef-1234567890ab" \ --scope "/subscriptions/{sub}/resourceGroups/rg-myapp/providers/Microsoft.KeyVault/vaults/prod-myapp-kv" # Create a user-assigned managed identity (reusable across resources)az identity create \ --name "myapp-identity" \ --resource-group "rg-myapp" \ --location "eastus" # Assign to multiple resourcesaz vm identity assign \ --name "myvm" \ --resource-group "rg-myapp" \ --identities "/subscriptions/{sub}/resourceGroups/rg-myapp/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myapp-identity" az aks update \ --name "myaks" \ --resource-group "rg-myapp" \ --assign-identity "/subscriptions/{sub}/resourceGroups/rg-myapp/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myapp-identity"DefaultAzureCredential tries multiple authentication methods in order: environment variables, managed identity, Azure CLI, Visual Studio, and more. This enables the same code to work in development (using your Azure CLI login) and production (using managed identity) without any changes.
Azure Key Vault's certificate management capabilities distinguish it from many competitors. Beyond simple storage, Key Vault can manage the entire certificate lifecycle including automatic renewal with integrated Certificate Authorities.
Certificate Capabilities:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263
# Create a self-signed certificateaz keyvault certificate create \ --vault-name "prod-myapp-kv" \ --name "myapp-tls-cert" \ --policy "$(az keyvault certificate get-default-policy)" # Create certificate with custom policycat > cert-policy.json << 'EOF'{ "issuerParameters": { "name": "Self" }, "keyProperties": { "exportable": true, "keySize": 4096, "keyType": "RSA", "reuseKey": false }, "secretProperties": { "contentType": "application/x-pkcs12" }, "x509CertificateProperties": { "keyUsage": ["digitalSignature", "keyEncipherment"], "subject": "CN=myapp.example.com", "subjectAlternativeNames": { "dnsNames": ["myapp.example.com", "api.myapp.example.com"] }, "validityInMonths": 12 }, "lifetimeActions": [ { "action": { "actionType": "AutoRenew" }, "trigger": { "daysBeforeExpiry": 30 } } ]}EOF az keyvault certificate create \ --vault-name "prod-myapp-kv" \ --name "myapp-tls-cert" \ --policy @cert-policy.json # Import an existing certificateaz keyvault certificate import \ --vault-name "prod-myapp-kv" \ --name "imported-cert" \ --file "certificate.pfx" \ --password "pfx-password" # Configure integrated CA (DigiCert example)az keyvault certificate issuer create \ --vault-name "prod-myapp-kv" \ --issuer-name "DigiCertCA" \ --provider-name "DigiCert" \ --account-id "DigiCert-Account-ID" \ --password "DigiCert-API-Key" # Create certificate from integrated CAaz keyvault certificate create \ --vault-name "prod-myapp-kv" \ --name "public-cert" \ --policy "$(cat ca-cert-policy.json)" # Policy with issuer set to DigiCertCAFor App Service TLS certificates, use App Service Certificates feature which integrates with Key Vault. Certificates stored in Key Vault are automatically available to App Services in the same subscription with proper RBAC. Configure App Service to reference Key Vault certificate by secret URI.
Key Vault integrates deeply with Azure services, enabling secrets injection, encryption key references, and certificate usage without managing credentials in application code.
123456789101112131415161718192021222324252627282930
// App Service configuration - appsettings linked to Key Vault{ "properties": { "siteConfig": { "appSettings": [ { "name": "DatabaseConnectionString", "value": "@Microsoft.KeyVault(VaultName=prod-myapp-kv;SecretName=db-connection-string)" }, { "name": "ApiKey", "value": "@Microsoft.KeyVault(SecretUri=https://prod-myapp-kv.vault.azure.net/secrets/api-key/)" }, { "name": "ApiKeyWithVersion", "value": "@Microsoft.KeyVault(SecretUri=https://prod-myapp-kv.vault.azure.net/secrets/api-key/abc123version)" } ] } }} // App Service must have:// 1. System-assigned managed identity enabled// 2. Key Vault Secrets User role on the vault// 3. Key Vault firewall allowing App Service access (or private endpoint) // Azure CLI setup:// az webapp config appsettings set --name mywebapp --resource-group rg-myapp \// --settings "DatabaseConnectionString=@Microsoft.KeyVault(VaultName=prod-myapp-kv;SecretName=db-connection-string)"For production workloads, configure Key Vault with private endpoints. This ensures traffic between your Azure resources and Key Vault traverses the Azure backbone network rather than the public internet. Combine with service endpoints or firewall rules to deny public access entirely.
Azure Key Vault provides multiple mechanisms for data protection and disaster recovery. Understanding these capabilities is essential for designing resilient secrets infrastructure.
Built-in Protection:
1234567891011121314151617181920212223242526272829303132333435363738394041424344
# Enable soft delete and purge protection (required for production)az keyvault update \ --name "prod-myapp-kv" \ --enable-soft-delete true \ --retention-days 90 \ --enable-purge-protection true # Backup individual secrets (encrypted blob)az keyvault secret backup \ --vault-name "prod-myapp-kv" \ --name "database-password" \ --file "database-password.backup" # Backup a keyaz keyvault key backup \ --vault-name "prod-myapp-kv" \ --name "encryption-key" \ --file "encryption-key.backup" # Backup a certificateaz keyvault certificate backup \ --vault-name "prod-myapp-kv" \ --name "tls-cert" \ --file "tls-cert.backup" # Restore to same or different vault (same tenant only!)az keyvault secret restore \ --vault-name "recovery-vault" \ --file "database-password.backup" # Recover soft-deleted vaultaz keyvault recover --name "deleted-vault" --location "eastus" # Recover soft-deleted secretaz keyvault secret recover \ --vault-name "prod-myapp-kv" \ --name "accidentally-deleted-secret" # List deleted vaults and secretsaz keyvault list-deletedaz keyvault secret list-deleted --vault-name "prod-myapp-kv" # Purge (permanently delete) - only if purge protection not enabledaz keyvault secret purge --vault-name "prod-myapp-kv" --name "old-secret"Disaster Recovery Strategy:
| Scenario | Mechanism | RTO/RPO |
|---|---|---|
| Accidental deletion | Soft delete recovery | Minutes / 0 data loss |
| Region outage | Automatic paired region failover | Minutes / Near 0 |
| Tenant/subscription loss | Backup restoration to new tenant | Hours / Last backup |
| Ransomware/corruption | Purge protection + versioning | Minutes / 0 data loss |
Key Vault backups can only be restored to vaults in the same Azure subscription AND geographic region. For cross-region or cross-subscription disaster recovery, you must maintain secrets in multiple vaults. Backup files are encrypted and tied to the source Azure AD tenant.
Azure Key Vault provides a comprehensive platform for secrets, keys, and certificates management within the Azure ecosystem. Let's consolidate the key concepts:
What's Next:
Having explored Azure Key Vault, the next page examines Kubernetes Secrets—the built-in secrets management for Kubernetes clusters. You'll learn about native K8s secrets, their limitations, and how to enhance security with external secrets operators and sealed secrets.
You now have a comprehensive understanding of Azure Key Vault's architecture, access control models, managed identities, certificate management, and disaster recovery capabilities. This knowledge enables you to design secure secrets infrastructure for Azure-centric workloads.