Azure Key Vault

Microsoft Azure hub

Azure Key Vault is a managed service for securely storing and controlling access to secrets, encryption keys, and TLS/SSL certificates, so credentials never need to be hardcoded in application config or source code. Applications authenticate via Entra ID identities and retrieve secrets at runtime through RBAC-scoped access policies, and every access is logged for audit purposes.

Azure Key Vault

Key Vault centralizes secrets management behind an access-controlled, audited service instead of scattering credentials across config files.

Why It Matters in Production

CRED's backend services authenticate to Key Vault using a Managed Identity, pulling the database password at startup rather than storing it in an environment variable that could leak via a misconfigured log line.

az keyvault secret set --vault-name cred-prod-kv
--name db-connection-string --value "Server=tcp:...;"

Security
Never grant "Purge" permission on a production Key Vault broadly — a purge permanently deletes a secret, bypassing the soft-delete recovery window.

Frequently Asked Questions

What specific problem does Key Vault solve that environment variables or config files don't?

Secrets in environment variables or config files end up in deployment logs, source control history, or container image layers if anyone's not careful, and rotating them means redeploying every service that references them. Key Vault centralizes secrets so applications fetch them at runtime via managed identity — no credential is ever embedded in code or config — and rotating a secret in Key Vault updates it everywhere it's referenced without a redeploy.

What's a common mistake when using Key Vault?

Fetching secrets on every single request instead of caching them in memory with a reasonable TTL, which adds unnecessary latency and can hit Key Vault's throttling limits under load. Also common: granting overly broad access policies (full vault access) to an application identity that only needs to read one specific secret — RBAC should be scoped as narrowly as the workload actually requires.