Secrets Management
Secrets management is the discipline and tooling for storing, distributing, rotating, and auditing credentials such as keys and tokens.
Definition
Secrets management covers the lifecycle of sensitive credentials — API keys, database passwords, signing keys, certificates — so they are never hardcoded, never widely readable, and always rotatable. It combines a storage service that encrypts at rest and controls access, delivery mechanisms that inject secrets at runtime, rotation policies that replace credentials on a schedule or on demand, and audit trails that record who read what. The goal is to shrink the window in which a leaked secret is useful.
Context and scope
Every application that authenticates somewhere has secrets; the discipline becomes critical as deployments multiply and human access to production is removed.
Common misconceptions
- Environment variables are enough — env vars leak through process listings, logs, and crash dumps, and cannot be rotated without a restart
- Encrypting secrets in the repo solves it — the decryption key then becomes the secret, and it too must be managed
- Rotation is a nice-to-have — a secret that cannot be rotated turns one leak into a permanent compromise
Anti-patterns
- Committing secrets to git, even in private repositories where history persists
- Sharing one long-lived credential across many services, so revocation breaks everything
- Granting read access to all secrets because scoping is inconvenient
Related concepts
Related examples
Authoritative source
What it is
Secrets management centralises credentials in a service that encrypts them, authenticates the caller, and returns the secret only to authorised workloads. Rather than baking a password into an image, an application authenticates to the manager and fetches its secret at start-up or on demand. The manager records every access, supports rotation, and can issue short-lived dynamic credentials that expire automatically, so there is often no static secret to steal at all.
Why it matters
Leaked credentials are a leading initial-access vector. Hardcoded secrets live in source history, container layers, and configuration files, and they rarely change. Once centralised, a secret has one authoritative source, can be scoped to a workload identity, and can be rotated without editing code. Short-lived credentials reduce the value of any single leak to near zero, which changes the economics of an incident.
How to use it well
Never store secrets in code or images; fetch them at runtime from the manager using a workload identity. Prefer dynamically generated, expiring credentials over static ones, and scope access per service and per environment. Automate rotation so it is routine, monitor for unused or over-privileged secrets, and scan repositories and build logs for accidental leaks. Treat every secret as already compromised the moment it cannot be rotated.