Secret Management
Secret management stores, distributes, rotates, and audits credentials so they never live in source, images, logs, or long-lived environment files.
Definition
Secret management is the lifecycle for credentials such as database passwords, API keys, signing keys, and certificates. A secret manager stores them encrypted, controls access by identity, injects them at runtime, rotates them on a schedule or on compromise, and audits every read. Secrets must not be committed to source control, baked into images, or printed in logs.
Context and scope
Secret management is required for cloud services, CI pipelines, and any system with privileged credentials. It becomes more important as teams and environments multiply and manual secret sharing becomes unmanageable.
Common misconceptions
- Environment variables are always safe — they are visible to child processes and can leak in crash dumps or logs
- A secret is safe because the repository is private — insiders, backups, CI logs, and cloned laptops still expose it
- Rotation is only for compromised secrets — routine rotation limits the value of an undetected leak
Anti-patterns
- Committing `.env` files or hard-coded keys
- Sharing one long-lived credential across services and environments
- Logging request headers, connection strings, or full configuration objects
Related concepts
Related examples
Authoritative source
A secret is a credential with a lifecycle
A secret is not a configuration value that happens to be sensitive. It has an owner, a scope, a rotation procedure, and an audit trail. Store secrets in a dedicated manager or the platform’s secret store, grant read access to a specific workload identity, and inject them at runtime rather than at build time.
const secret = await secretManager.accessSecretVersion(
`projects/app/secrets/${name}/versions/latest`
);The example shows runtime retrieval; the exact API varies. The important properties are access control, audit, and no secret in the image or repository.
Do not leak through logs and errors
Most leaks are accidental: a connection string in an exception, an authorization header in a request log, a .env file copied into a container. Configure redaction, avoid logging configuration objects, and scan repositories and build artifacts for secret patterns. A secret that appears in CI logs should be treated as compromised.
Rotate and revoke
Routine rotation limits the lifetime of an undetected leak. On suspected compromise, revoke first, verify the old credential fails, then distribute the new one. Automate rotation where possible and keep an emergency manual procedure. Use short-lived credentials or workload identity instead of static keys whenever the platform supports it.
When to use it
Use a secret manager for every credential that grants access to production data or infrastructure. The advantage is centralized control, audit, and rotation; the drawback is another dependency and the need for a bootstrap credential. Compared to environment files, a secret manager is more complex but far easier to audit and revoke.