Chapter 73 — Secrets management and credential lifecycle
In one sentence
Secrets management is not where strings are stored; it is the lifecycle of creation, distribution, use, rotation, detection, and revocation.
The hierarchy
- Prefer no secret: workload identity, instance identity, OIDC federation.
- Prefer short-lived credentials over static credentials.
- If static secrets are unavoidable, store them in a secrets manager.
- Rotate and monitor every secret.
- Have emergency revocation that has been tested.
What counts as a secret
- API keys;
- database passwords;
- SSH private keys;
- signing keys;
- OAuth client secrets;
- webhook signing secrets;
- service-account JSON files;
- refresh tokens;
- CI/CD tokens;
- private certificates.
Real-world scenario: leaked CI token
An engineer pastes a CI log into a ticket. The log includes:
Authorization: Bearer ghp_...
The token can read private repositories and trigger workflows. The response is:
- revoke token immediately;
- search logs/artifacts/tickets for spread;
- identify what the token could access;
- review audit logs for use after exposure;
- rotate dependent credentials if the token could read them;
- add masking and secret scanning to CI.
Design checklist
- Can this workload use cloud/workload identity instead of a stored secret?
- Is the secret scoped to one purpose?
- Is it environment-specific?
- Is rotation automated?
- Do logs mask it?
- Can detection tell us it was used from an unusual source?
- Is revocation tested?
Across the series
- Delivering secrets to a service without environment variables: systemd's
LoadCredential(root-only files exposed only to oneDynamicUserservice) and Kubernetes secret mounts in the Linux guide, Chapter 82. Secure coding in Go, including secret handling: Go guide, Chapter 47.