Cyber Coffee · English edition
Where secrets belong: managing secrets with Azure Key Vault
The architecture that changes the question from “How do I hide the key better?” to “Why would there need to be a key to hide?”
· 4 min read
A secret in an environment variable accidentally committed to a repository, an API key left in a config file “just until the test deployment,” a hardcoded credential “just for a quick test” that nobody removed afterward: leaked secrets are among the most mundane, and at the same time most serious, causes of security incidents. Mundane because they require no sophisticated attack; serious because a leaked credential provides direct access without exploiting anything. Most cases are preventable through architectural discipline, rather than heroic manual reviews.
A secret scanner is a fire alarm, not prevention
Gitleaks and equivalent tools tell you that a secret has leaked after it has already leaked, is already in the repository history and has potentially already been cloned by someone. This is useful and necessary, but fundamentally reactive: a fire alarm does not prevent a fire; it only tells you sooner that one has started.
Real prevention is architectural: the secret should never be present as text in source code to be scannable in the first place. A centralized vault such as Azure Key Vault changes the team’s question from “How do I avoid accidentally committing a secret?” to “Why would there be a secret to commit?” The second question is structural; the first depends on human discipline that will eventually fail.
Managed identity eliminates the root credential
The pattern that addresses the problem at its foundation, rather than its edges: the application authenticates to Key Vault using an Azure managed identity, with no static credential stored anywhere, whether in an environment variable, a configuration file or a CI/CD pipeline.
There is no secret to leak because there is no corresponding static secret: the identity belongs to the workload itself, whether an App Service, a Function or a container, and is validated by Azure Active Directory at the time of the call. This is the difference between hiding the key somewhere better protected and simply not needing a key for that link in the chain. Every static credential eliminated removes an entire category of possible incident, rather than merely making it less likely.
Rotation only works if it is automatic
A secret that depends on manual rotation is, in practice, not rotated. Every team that has been through this knows it and pretends not to, because admitting it means acknowledging a debt nobody has time to pay. Manual rotation requires remembering, coordinating a redeployment and ensuring no service keeps pointing to the old version: enough work that, in practice, it happens once and never again.
Centralizing secrets in a vault makes automatic rotation viable: the secret changes in a single place, and applications consuming it through an SDK retrieve the new version without redeployment, provided the code fetches the value from Key Vault at runtime or uses a short-lived cache, rather than capturing it once at startup and never refreshing it. Manual rotation is guaranteed debt; automatic rotation is the only realistic way for a long-lived credential to be replaced regularly instead of never.
Environment separation and least privilege
Separate vaults, or at least separate access scopes, for development, staging and production complete the model, with access granted according to least privilege and every secret access logged. Compromising staging then does not automatically hand over production credentials, and an audit trail records who accessed which secret and when. That information becomes critical precisely when investigating an incident, when it is too late to start collecting it.
What to take away
The ultimate goal of good secrets management is not to store secrets more carefully or behind more layers of obfuscation. It is to reduce, as close to zero as possible, the number of secrets that exist as static text needing to be stored somewhere. Managed identity removes the root credential wherever possible; for what remains, centralization in Key Vault enables real automatic rotation; and environment separation with least privilege limits the blast radius of anything that can still leak. Secret scanning remains valuable as a safety net for what escapes the design, but never as the first line of defense.