Inventory purpose and ownership
Record each secret’s type, owner, issuer, consumer, environment, scope, creation date, rotation policy, and revocation path. Use a nonsecret fingerprint so operators can identify the credential without exposing its value.
Link secret metadata to workloads, repositories, pipelines, and partner integrations. Unowned or unknown credentials should be resolved, not accepted as permanent background risk.
Protect creation and delivery
Generate bearer secrets with a cryptographically secure random source and narrow their authority. Separate the visible identifier from the secret value and store a verifier instead of the original when recovery is unnecessary.
Deliver credentials through an authenticated, auditable channel. Prefer platform identity and runtime brokers for workloads so long-lived values do not need to be copied into deployment files.
Prevent runtime and pipeline leaks
Keep secrets out of source history, container images, tickets, chat, request URLs, crash reports, and logs. Pre-commit and server-side scanning are guardrails, not a reason to delay revocation after a real leak.
Restrict which branches and jobs can access production credentials. Review third-party build actions, separate build and deployment authority, and ensure untrusted pull requests never receive sensitive variables.
Automate rotation and revocation
Use a short overlap: issue a replacement, deploy it, observe successful use, and revoke the old value. Measure whether old credentials stop appearing rather than assuming rotation completed.
Test emergency revocation, including downstream tokens, caches, replicas, and derived sessions. A revoked client secret may not automatically invalidate every access token issued earlier.
Implementation checklist
- Assign owner, purpose, scope, environment, and revocation path.
- Generate strong values and separate IDs from secrets.
- Use authenticated, auditable delivery.
- Prevent secrets in code, images, logs, and tickets.
- Automate overlapping rotation and verify retirement.
- Test emergency revocation through the full credential chain.
Frequently asked questions
Is a vault enough for secrets management?
No. A vault helps protect storage and access, but the program also needs scope, ownership, delivery, runtime handling, rotation, revocation, and leak response.
Are environment variables safe for secrets?
They are common but can leak through process inspection, diagnostics, or crash tooling. Platform-specific mounted files, local agents, or runtime secret APIs may offer stronger controls.
How often should API keys rotate?
Choose frequency based on authority, exposure, revocation speed, and operational reliability. Short-lived credentials are preferable when practical; static keys need tested rotation and monitoring.
