Azure Key Vault, explained: get the secrets out of your code
A connection string in a config file is a breach waiting for a git push. Key Vault is where those secrets go instead — a central, access-controlled, audited store so your code holds a reference to a secret, never the secret itself.
Ask where an application keeps its database password, its API keys, its TLS certificate, and the honest answer in a lot of codebases is "somewhere in the repo, probably." That is the exact habit Azure Key Vault exists to break. Microsoft describes it as "a secure secrets store, providing management for secrets, keys, and certificates, all backed by Hardware Security Modules." In plain terms: it is the locked cabinet where credentials live, so they stop living in your source code.
Three things it holds
Key Vault solves three related problems, and it is worth knowing which is which:
| Type | What it is | Example |
|---|---|---|
| Secrets | Arbitrary sensitive strings you store and tightly control | A database connection string, an API key, a token |
| Keys | Cryptographic keys used to encrypt data, which can be HSM-protected | The key behind storage or database encryption |
| Certificates | TLS/SSL certificates it can provision, manage, and auto-renew | The HTTPS cert on your web app |
The unifying idea: instead of scattering this material across apps and config files, you centralize it in a vault that controls distribution. Your app then fetches what it needs at run time via a URI — "There's no need to store security information in applications," as the docs put it, and no need to make it part of the code.
How access works: authenticate, then authorize
A vault is only as good as its lock, so getting in takes two steps. Authentication — proving who you are — always happens through Microsoft Entra ID. Authorization — deciding what you may do — happens one of two ways:
- Azure RBAC (recommended). The same role model as the rest of Azure: assign a role like Key Vault Secrets User to an identity, and it can read secrets. RBAC governs both managing the vault and accessing the data inside it, and it is consistent with how you control everything else.
- Key Vault access policies (the older model). A per-vault list of who can do which operations on data. It only covers data access, not vault management, and it lives apart from Azure's main role system — which is exactly why RBAC is now the recommended path.
The pattern that makes it click: a managed identity reads a secret
Here is where Key Vault stops being abstract. Picture a web app that needs a database password. The old way: paste the password into config. The Key Vault way, done properly, uses no password your code can see at all:
- The secret lives in Key Vault.
- The web app has a managed identity — an Azure-managed identity with no credentials you hold.
- You grant that identity the Key Vault Secrets User role on the vault.
- At run time the app authenticates as its managed identity and reads the secret by URI.
Now trace what a leak would need. There is no secret in the repo, no secret in the app's config, and no credential for the identity for anyone to steal. The password exists in exactly one governed, audited place, and only one identity can read it. That is the whole point — Key Vault and managed identity are two halves of the same "no secrets in code" story.
Your code should hold the address of a secret, never the secret. Key Vault is the address.
You can log every access to a vault to Azure Monitor, so "who read this secret, and when?" has an answer. And features like soft-delete and purge protection mean a fat-fingered or malicious deletion of a key does not become an unrecoverable outage. Centralizing secrets does not just reduce leaks; it makes them investigable.
When to reach for it
Effectively always, the moment an application has a secret. If your code needs a password, a key, an API token, or a certificate, that material belongs in Key Vault and gets read at run time by an identity you granted — not typed into a config file and hoped over. Set the vault up once, prefer RBAC, hand access to a managed identity, and you have moved an entire category of "how did that credential leak?" incidents off the table before you ever ship.