What Is Azure Key Vault?
Azure Key Vault is a managed service for securely storing and tightly controlling access to secrets (connection strings, passwords), keys (used for encryption and signing, optionally backed by FIPS 140-2 validated hardware security modules), and certificates, centralizing sensitive material outside of application code and configuration files so it can be rotated, audited, and access-controlled independently.
Cricket analogy: It's like a franchise storing its most sensitive documents — player contracts, medical records — in a locked vault at team HQ rather than leaving copies in every coach's kit bag, with a sign-in log for anyone who accesses them.
Access Models: Vault Access Policies vs Azure RBAC
Key Vault supports two access control models — the legacy vault access policy model, which grants coarse-grained key/secret/certificate permissions directly on the vault, and the recommended Azure RBAC model, which uses standard role assignments like Key Vault Secrets User scoped down to individual keys, secrets, or certificates for consistency with the rest of Azure's permission system and support for Conditional Access and Privileged Identity Management.
Cricket analogy: The legacy access policy model is like a ground giving a blanket 'staff pass' that lets someone into every area, while RBAC is like the modern ICC accreditation system that grants access down to a specific stand, gate, or even a single dressing room.
Managed Identities and Secret Rotation
Applications should retrieve secrets from Key Vault using a managed identity rather than embedding a client secret, eliminating the credential entirely; combined with automatic secret rotation and versioning (where every update creates a new version while old versions remain retrievable for audit or rollback), and integration with Event Grid to notify systems when a secret is nearing expiry, this removes the most common source of leaked credentials — hardcoded secrets in source code.
Cricket analogy: This is like a stadium's automated turnstile recognizing a season-ticket holder's biometric scan directly, rather than the fan needing to carry and periodically renew a physical paper pass that could be lost or copied.
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
# DefaultAzureCredential uses the app's managed identity automatically
credential = DefaultAzureCredential()
client = SecretClient(
vault_url="https://myapp-vault.vault.azure.net/",
credential=credential,
)
# Retrieve the latest version of a secret
db_password = client.get_secret("db-password").value
# Set a new version; the old version remains retrievable for rollback
client.set_secret("db-password", "new-rotated-value")Key Vault supports 'soft delete' (retaining deleted vaults and objects for a recovery period, 90 days by default) and 'purge protection' (preventing permanent deletion even by an Owner until the retention period expires), which together guard against accidental or malicious permanent data loss.
Certificates and Keys
Beyond secrets, Key Vault manages TLS/SSL certificates end-to-end — generating certificate signing requests, integrating with supported certificate authorities for issuance, and auto-renewing before expiry — and manages cryptographic keys for operations like encrypt/decrypt and sign/verify, either as software-protected keys or HSM-protected keys, without the key material ever leaving the vault boundary during those operations.
Cricket analogy: HSM-protected keys are like the Ashes urn itself, which never physically leaves its display case even when photographed or examined — you interact with it through controlled means without ever removing it from its secure enclosure.
Never store secrets in application source control, environment variable files committed to a repo, or container image layers — even with Key Vault available, a common mistake is fetching a secret once and then caching it indefinitely in code without honoring rotation, leaving stale credentials in use long after they were rotated in the vault.
- Key Vault centralizes secrets, keys, and certificates outside of application code.
- RBAC access model is recommended over the legacy vault access policy model.
- Managed identities eliminate the need to store credentials for accessing the vault itself.
- Every secret update creates a new version; old versions remain retrievable.
- Soft delete and purge protection guard against accidental or malicious permanent deletion.
- Key Vault manages TLS certificate lifecycle including auto-renewal before expiry.
- HSM-backed keys never leave the vault boundary during cryptographic operations.
Practice what you learned
1. What is the recommended access control model for Azure Key Vault today?
2. Why should applications use a managed identity to access Key Vault instead of a client secret?
3. What happens when you update a secret's value in Key Vault?
4. What does 'purge protection' add on top of 'soft delete' in Key Vault?
5. What distinguishes an HSM-protected key from a software-protected key in Key Vault?
Was this page helpful?
You May Also Like
Azure Active Directory (Entra ID)
Microsoft's cloud-based identity and access management service, renamed Microsoft Entra ID, covering tenants, users, groups, app registrations, and conditional access.
Azure RBAC Explained
Azure's role-based access control system for granting fine-grained permissions to resources through role definitions, scopes, and role assignments.
Azure SQL Database Basics
A fully managed relational database-as-a-service built on the SQL Server engine, covering deployment models, elastic pools, and built-in high availability and security.