Azure Key Vault
What it is
Azure Key Vault is a managed Azure service for storing and controlling access to three sensitive object types: secrets (such as passwords and connection strings), keys (cryptographic keys), and certificates. It gives an application a protected place to retrieve a value at runtime instead of placing that value in code, a file, or a pipeline definition.
Why it exists
Storing secrets in code, config files, or plaintext is a top security failure. Key Vault centralizes secrets behind Entra ID + RBAC access control, rotates them, and keeps them out of code — the foundation of secrets-management.
Key ideas
- A secret, key, and certificate have different purposes. Do not call every sensitive value a “key.” A database password is normally a secret; an encryption key performs cryptographic operations; a certificate packages a public key and related identity material.
- A vault supports Azure RBAC or its legacy access-policy authorization model. Choose and operate the intended model deliberately; the calling identity still needs the appropriate permission.
- Use a managed identity or other short-lived/federated identity where supported. The vault’s protection is weakened if a long-lived credential to reach it is hard-coded nearby.
- Network access, logging, deletion protection, retention, and rotation are separate configuration decisions. A vault is not automatically safe merely because it exists.
Northwind example
Northwind stores a payment-provider credential as a Key Vault secret. Its ordering app’s managed identity has permission to retrieve that one secret, while Luis does not put the value in source code or an App Service setting shared with every developer. When the provider credential rotates, the app retrieves the current value at runtime according to Northwind’s tested rotation plan. Key Vault holds the secret; RBAC and the managed identity control who can obtain it.
Common confusion
- Key Vault is not a replacement for all application configuration. Keep non-sensitive configuration outside the secret store where appropriate.
- Granting Key Vault access is not the same as granting general Azure subscription access.
- Secret masking in a build log is helpful but does not undo a secret already committed or sent to an untrusted endpoint. Revoke and rotate exposed secrets.
Safe use
Give each workload only the objects and operations it needs, restrict network paths where the design requires it, enable appropriate recovery protection, and test access plus rotation. Avoid broad vault-wide access for a convenience shortcut.
Related
secrets-management · best-practice-secrets · service-principal · managed-identity · rbac · northwind-traders-case-study
Diagram
Diagrams courtesy of Microsoft Learn / Azure docs: key-vault/general/basic-access
📘 Source: Microsoft Learn — Azure Key Vault overview, checked 2026-09-16.