Identity & Access · Chapter 6
Secrets management
The problem every engineering organisation has, and most solve badly.
Applications need credentials: database passwords, API keys, signing keys, certificates. Where those live is one of the most consequential and least examined decisions in a codebase.
The maturity ladder
| Level | Where the secret lives | The problem |
|---|---|---|
| 0 | Hard-coded in source | In every clone, every fork, and git history forever |
| 1 | In a .env file on the server | Unrotatable in practice; nobody knows who has read it |
| 2 | In CI/CD variables | Better, but broad blast radius and often visible in logs |
| 3 | In a secrets manager, fetched at boot | Good. Still long-lived, still one leak from exposure |
| 4 | Dynamic, short-lived, fetched per use | The target. A leaked credential expires before it is useful |
| 5 | No secret at all — workload identity | The endpoint. The platform attests the workload; nothing to leak |
Levels 4 and 5 are what modern secrets tooling is for. Cloud workload identity — IAM roles for service accounts, managed identities, OIDC federation from CI — removes the secret entirely: the platform proves what the workload is, and the workload receives a short-lived token. The best secret is the one that does not exist.
What to check
- Has the repository ever contained a secret? History matters — rotating without purging history leaves it retrievable. Secret scanning on every push, and on history, is now table stakes.
- Can you rotate without downtime? If not, rotation will not happen after an incident when it matters most. Practise it.
- Who can read each secret, and is that logged? A vault with permissive read policies is a well-organised secret sprawl.
- What is the lease duration? This single number tells you most of what you need to know about the maturity of the setup.