secrets-management
Installation
SKILL.md
Secrets Management
The two failure modes are: (1) the secret leaks, and (2) the secret can't be rotated when it does. Most "secrets management" advice is downstream of those two facts.
Core principles
- Never in source control. Not in
.env.example, not "just for staging," not "encrypted with my GPG key." The moment a secret is committed, assume it is leaked — Git history is forever, and forks/clones make redaction impossible. - Never logged. Structured loggers should redact known-secret fields by default. Stack traces with bound parameters routinely include passwords; this is a recurring leak vector.
- Rotation must be a routine event, not an incident. If rotating the DB password requires a war room, you've designed it wrong. The system should rotate without anyone noticing.
- Identity, not secrets, where possible. A workload with a verifiable cloud identity (IRSA, GCP Workload Identity, Azure Managed Identity) doesn't need a long-lived API key. Eliminate the secret rather than manage it.
- Least privilege, narrow scope, short TTL. A secret that's read-only, scoped to one resource, and expires in an hour is much less dangerous than an admin token that lives forever.
- Audit access. Every read of a high-value secret should produce a log entry tied to a principal, with rate-limiting and anomaly alerts on top.