Secrets Management: Getting Credentials Out of Code and Config

Applications need credentials — database passwords, API keys, certificates, tokens for other services — and the default place they end up is a configuration file or an environment variable set from one. That works until you need to rotate one, audit who used it, or find out where it is, at which point the absence of a system becomes the problem.

Why secrets end up in repositories

Not carelessness, mostly. A developer needs the application to run locally, puts the credential in a configuration file, and commits it because the file is needed to run. It works, so nobody revisits it.

The consequence is that the secret is in the version history permanently, readable by everyone with repository access, present in every clone, and surviving deletion of the line. Removing it requires rewriting history, which is disruptive and frequently incomplete — and the right response is to treat it as compromised and rotate.

Public repositories are scanned continuously for committed credentials, and the time from a key appearing to being used has been measured in minutes. Private repositories are safer only until someone forks, clones to a personal machine, or the repository is made public by mistake.

What a secrets manager provides

Four things a configuration file cannot.

Centralised storage, encrypted at rest with the master key protected in hardware, so the secrets exist in one place you can reason about rather than scattered across configuration.

Access control per secret, so a service retrieves only what it needs and a person's access is separate from an application's.

Audit logging of every retrieval — who, what, when. This is the capability that makes an incident investigable, and it is entirely absent when credentials live in files.

Rotation without redeployment, because the application fetches at runtime. A secret changed in the manager takes effect without a release, which is what turns rotation from a project into a routine operation — the practical requirement described under key rotation.

Dynamic secrets

The strongest pattern and worth knowing as the target state.

Instead of storing a long-lived database password, the manager holds credentials to create them. An application requests access, the manager generates a new database user valid for an hour, and revokes it when the lease expires.

The consequences are substantial. There is no long-lived credential to leak. Every access is attributable to a specific lease. Rotation is automatic because nothing lives long enough to need it. And revoking access during an incident means revoking a lease rather than coordinating a password change across every consumer.

The cost is integration work and a dependency on the manager being available, which makes it a genuine availability consideration — the choice examined under fail-open versus fail-closed, where failing closed is correct and needs planning for.

How the application authenticates

The question people notice immediately: if secrets are in a manager, what credential lets the application retrieve them? Storing that in a file recreates the problem one level up.

The answer is platform identity. A cloud workload authenticates with the identity its platform assigns it, a container with a service account token the orchestrator provides, a machine with a certificate bound to hardware — the property described under TPM. In each case the credential is issued by infrastructure, short-lived, and not something a person can copy out of a file.

Where no platform identity exists, a bootstrap token delivered at provision time and immediately exchanged for a longer-lived identity is the fallback.

Detection and response

Scan repositories for committed secrets automatically, in the pipeline and as a pre-commit hook, and scan the history rather than just the current state. Scan build logs and container images too — a secret passed as a build argument is baked into an image layer and survives deletion, as under container images.

When a secret leaks, the order matters: rotate first, then remove it from the repository, then investigate what used it and whether it was used by anyone else. Removing it first while the credential remains valid achieves nothing, and the sequence is the same reasoning as under credential breach response.

Monitor retrievals for anomalies — a secret fetched from an unexpected workload, or far more often than usual, is a signal that only exists because the manager logs it.

Exam angles

Know that credentials committed to a repository persist in history permanently and must be rotated rather than deleted. Name centralised encrypted storage, per-secret access control, audit logging and runtime rotation as what a secrets manager provides. Know dynamic secrets as short-lived credentials generated on request, removing long-lived secrets entirely. Recognize platform-issued workload identity as how an application authenticates to the manager without a stored credential.