Azure Key Vault’s auto-unseal feature lets your HashiCorp Vault cluster recover from restarts without manual intervention by using an Azure Key Vault as an external unseal mechanism.
Let’s see auto-unseal in action. Imagine a Vault cluster with three nodes, vault-0, vault-1, and vault-2, running in Azure. They’re all configured to use the same Azure Key Vault for auto-unseal. If vault-0 restarts, it doesn’t hang in an unsealed state. It reaches out to the Azure Key Vault, retrieves the unseal key using its managed identity, and uses that to unseal itself. The other nodes, during their own restarts or if they were down, do the same. No operator needs to type vault operator unseal.
Here’s how you set it up. First, you need an Azure Key Vault.
az keyvault create --name my-vault-for-auto-unseal --resource-group my-resource-group --location eastus
Next, you need to grant your Vault cluster’s managed identity (or the service principal it uses) permission to access this Key Vault. The managed identity needs GET and LIST permissions on secrets.
If you’re using Azure Kubernetes Service (AKS) with Workload Identity, you’d create a user-assigned managed identity:
az identity create --name vault-identity --resource-group my-resource-group
Then, assign a role to this identity on the Key Vault. The Key Vault Secrets Officer role is often sufficient.
az role assignment create --role "Key Vault Secrets Officer" --assignee <vault-identity-client-id> --scope /subscriptions/<subscription-id>/resourceGroups/my-resource-group/providers/Microsoft.KeyVault/vaults/my-vault-for-auto-unseal
You’ll also need to configure Vault to use this managed identity. This is typically done in the Vault Helm chart’s values.yaml or via direct configuration. For AKS with Workload Identity, you’d annotate the Vault service account:
# values.yaml for Vault Helm chart
global:
enabled: true
azure:
cloud: AzurePublicCloud
tenant_id: <your-azure-tenant-id>
subscription_id: <your-azure-subscription-id>
resource_group: my-resource-group
keyvault_name: my-vault-for-auto-unseal
use_managed_identity: true
# If using user-assigned identity:
# managed_identity_client_id: <vault-identity-client-id>
# ... other Vault config
With auto-unseal enabled, the first time Vault starts, it will generate an unseal key and store it encrypted in the Azure Key Vault. Subsequent restarts will use this stored key. The vault status command will show Sealed: false if auto-unseal is operational.
The critical lever you control here is the Azure Key Vault’s access policy or Azure RBAC role assignment. If Vault cannot authenticate to Azure Key Vault or lacks the necessary permissions to GET and LIST secrets, it will fail to unseal.
A surprising aspect of auto-unseal is that the key stored in Azure Key Vault is not the master encryption key for Vault’s data. Instead, it’s a key encryption key (KEK). Vault generates its primary data encryption key (DEK), encrypts that DEK using the KEK stored in Azure Key Vault, and then stores the encrypted DEK. On restart, Vault fetches the encrypted DEK, retrieves the KEK from Azure Key Vault, decrypts the DEK, and then uses the DEK to decrypt its data. This means even if the KEK in Azure Key Vault is compromised, the actual data encryption keys are still protected by Vault’s internal key management.
Once auto-unseal is working, you’ll want to consider how to manage the KEK itself, which might involve Azure Key Vault’s key rotation features or access policies.