key vault secrets
What it is
An Azure Key Vault secret is a sensitive string value stored in Azure Key Vault. Typical secrets include passwords, connection strings, API keys, and client secrets. Key Vault encrypts the value at rest and returns a secret identifier that an authorized application can use to retrieve it.
Think of a locked envelope in a controlled cabinet. The label tells you which envelope to request; it does not reveal the contents or give everyone permission to open it.
Why it exists
Secrets placed in source code, ordinary configuration, chat messages, or a shared spreadsheet are difficult to rotate and easy to expose. Key Vault separates the sensitive value from the application package and gives access only to approved identities.
Key ideas
- A secret is generic data represented as a string to applications. Key Vault does not understand whether it is a database password, vendor token, or connection string; the application defines the meaning.
- A secret has versions. Rotation commonly creates a new version, then applications move to it after validation. Plan a safe overlap so an old credential is not disabled before consumers can use the replacement.
- Azure RBAC is the recommended way to grant a principal access to secrets. Give an application’s managed identity only the actions it needs, such as reading a specific vault’s secrets.
- Secret names, tags, and identifiers are not secret. Someone allowed to list or get a secret can read its tags, so do not put sensitive data in metadata.
- Expiration and not-before attributes help describe and govern a secret’s intended lifetime, but the application must still plan rotation and validate its own credential behavior.
Northwind example
Northwind’s receipt service uses its managed identity to read the current database connection secret from Key Vault at startup or through an approved refresh design. Maya grants that identity access only to the production vault it needs. When the database password rotates, the team creates a new secret version, tests the service, then retires the old credential under their rotation procedure. The password never goes into the receipt service’s repository or App Configuration values.
Secret versus key and certificate
| Key Vault object | Typical purpose |
|---|---|
| Secret | Store a sensitive value that an application reads. |
| Key | Perform cryptographic operations without exposing key material in normal application code. |
| Certificate | Manage a certificate and its related material for TLS or other certificate-based use. |
They share a vault but have distinct access controls and operations.
Common confusion
- Encrypting a secret at rest does not make broad access safe. Least-privilege permissions and audit review still matter.
- A vault is not an application configuration database. Keep ordinary settings in App Configuration and reserve secrets for sensitive values.
- A secret value is not automatically rotated or propagated to a running application. Rotation and refresh require an explicit design.
Related
key-vault · azure-app-configuration · managed-identity · service-principal · sas · northwind-traders-case-study
Sources and re-audit
- Microsoft Learn — About Azure Key Vault secrets, checked 2026-09-16.