Secret management

What is secret management?

Secret management is how you store credentials and hand them out safely: database passwords, API keys, connection strings, access tokens (including the short-lived ones an OAuth flow hands out), and TLS certificates that let one system prove who it is to another. The goal is to keep this material out of your code and configuration files and put it in one place where access is controlled, logged, and revocable.

A secret is not ordinary config. Whoever holds it can usually read data, change records, or run up a bill. So it belongs in a dedicated secret store, not in a script, a spreadsheet, a chat message, or a screenshot.

Tools built for this include Azure Key Vault, AWS Secrets Manager, and HashiCorp Vault. Each gives you a vault that holds the secret, an identity check on every request, and a log of who read what and when.

Secrets in Git

The most common way secrets leak is the simplest: someone hardcodes an API key or a connection string, commits it, and pushes. OWASP calls this out directly, noting that many organisations have secrets hardcoded in plaintext and scattered through configuration files.

The trap is that deleting the line later does not undo it. Git version control keeps history, so the value stays in an earlier commit, and anyone with access to the repository, a clone, or a fork can still read it. Removing it from the current version only hides it from a casual reader.

Once a secret has been committed, the only safe response is to treat it as exposed and rotate it. Revoke the old value, issue a new one, and update the secret store. Rewriting history to scrub the commit is possible but risky, and it does not help if someone already pulled the repo, which is why the reliable fix is to rotate the secret.

How a secrets manager works

A secrets manager keeps each secret in an encrypted vault that nothing reads anonymously. Every request is authenticated, so the store knows which application or user is asking, and authorised, so it returns only the secrets that identity is allowed to see. Azure Key Vault, for example, authenticates through Microsoft Entra ID and controls access with role-based access control.

Your application fetches the secret at runtime instead of carrying it. The credential lives in the vault, the app asks for it when it needs to connect, and it never lands in the source tree. AWS Secrets Manager describes exactly this: you replace a hardcoded credential with a runtime call that retrieves it when you need it.

Two habits keep this safe in practice. Apply least privilege, so each service reaches only the secrets it actually uses, and give every application and environment its own secret. If production and staging share one database password, a leak in either one exposes both. That fine-grained, per-service access is the same discipline behind a zero-trust data architecture.

The store also logs access: who read which secret, when, and whether the request succeeded. That audit trail feeds directly into data governance.

Rotation and short-lived credentials

Even a well-stored secret is a standing risk. If it never changes, a copy taken today still works next year. Rotation fixes that. You replace the value on a schedule, and any stolen copy stops working at the next turn. AWS Secrets Manager can rotate on a schedule for you, and because the app reads the current value at runtime, rotating it does not mean redeploying every client.

Shorter-lived is stronger. A credential that expires in an hour is far less useful to an attacker than one that lasts a year. HashiCorp Vault takes this to its conclusion with dynamic secrets: instead of holding a standing password, Vault generates a fresh credential the moment a client asks, attaches a lease with a time-to-live, and revokes it automatically when the lease expires. The secret did not exist before the request and is gone soon after, which shrinks the window in which it can be abused.

The stronger answer: store no secret at all

The best-controlled secret is the one that does not exist. If a workload runs on cloud infrastructure, you can often give the workload an identity instead of a credential. On Azure this is a managed identity, on AWS it is an IAM role, and in a build pipeline it is OIDC federation. The platform issues a short-lived token to that identity at runtime, and the application uses it to reach the database or storage it is authorised for.

Be precise about what this changes. A managed identity does not hide the credential, it removes it. Microsoft's own wording is blunt: a managed identity replaces secrets such as access keys or passwords, and the credentials are not even accessible to you. There is no API key in a vault and no password in an environment variable, so there is nothing to rotate and nothing to leak, because no stored secret exists in the first place.

The same idea covers your CI setup. Rather than pasting a long-lived cloud key into your pipeline settings, OIDC federation lets the pipeline present a short-lived identity token from its provider and exchange it for cloud access for the length of that run. When the job ends, the access is gone.

What to watch out for with secret management

Do not log secret values.
Error logs and traces are not a safe store. Mask API keys, tokens, and connection strings before anything writes them, or a debug log becomes the leak.

Environment variables are only a first step.
Reading a secret from an environment variable keeps it out of code, but it gives you no rotation, no per-request authorisation, and no audit trail. For anything in production, a real secret store earns its place.