Azure Key Vault doesn’t just store secrets; it actively manages their lifecycle, acting as a central, hardened repository for your application’s most sensitive credentials.
Let’s see it in action. Imagine an application needing a database connection string. Instead of hardcoding it or storing it in a config file, the app fetches it from Key Vault.
# Example CLI command to get a secret
az keyvault secret show --vault-name my-key-vault --name MyDbConnectionString --query value -o tsv
This command, run by the application’s managed identity, retrieves the MyDbConnectionString from my-key-vault. The output is the actual connection string, which the application then uses. This process is auditable, and the secret itself never leaves the secure boundaries of Key Vault.
The core problem Key Vault solves is the secure management of secrets across distributed applications and services. Before Key Vault, secrets were often scattered, insecurely stored, or rotated manually, leading to vulnerabilities. Key Vault centralizes this, providing:
- Secure Storage: Secrets are encrypted at rest using hardware security modules (HSMs) if configured.
- Access Control: Fine-grained permissions using Azure RBAC or access policies, allowing you to grant specific identities (users, applications, managed identities) access to specific secrets.
- Auditing: Comprehensive logs of all access and management operations, crucial for compliance and security monitoring.
- Automatic Rotation: Built-in capabilities to automatically rotate secrets, especially useful for certificates and SQL Server credentials.
Internally, Key Vault is a managed Azure service. When an application requests a secret, its identity is authenticated by Azure AD. If authorized, Key Vault retrieves the encrypted secret, decrypts it, and returns it to the application. The encryption keys themselves are managed within Key Vault, often backed by HSMs, ensuring that even Microsoft cannot access your raw secrets.
You control Key Vault through its API, the Azure CLI, or the Azure portal. Key configuration levers include:
- Vault Properties: Enabling or disabling purge protection, setting retention periods for soft-deleted secrets, and configuring network access (e.g., private endpoints).
- Access Policies/RBAC: Defining who can get, list, set, or delete secrets, keys, and certificates. For example, granting a specific App Service’s managed identity
GETpermissions on secrets. - Secret Versions: Key Vault supports versioning of secrets. When you update a secret, a new version is created. Applications can be configured to retrieve the latest version or a specific historical version.
- Key Rotation for SQL: For SQL Server databases, Key Vault can be configured to automatically rotate the SQL login password. This involves setting up a Managed Identity for Key Vault, granting it permissions on the SQL server, and configuring the Key Vault secret to point to the SQL server.
The most surprising aspect of Key Vault’s secret rotation for SQL Server is how it leverages the same Managed Identity that reads the secret to update the SQL Server login. When the rotation is triggered, Key Vault uses its Managed Identity’s permissions on the SQL server to change the password associated with the login it’s managing. This creates a closed loop: Key Vault has the credentials to change the password, and it uses those credentials to perform the change, then updates the secret it stores with the new password.
The next logical step is to explore integrating Key Vault with Azure Policy for automated governance and compliance checks.