Secrets handling inside customer environments
Updated
Never yours, never in code: the rotation, scoping and drill routine for credentials on someone else's systems.
Secrets discipline is simple to state and easy to postpone. The routine below makes postponement visible.
The short answer
Customer vault, runtime injection, least scope, dated rotation, leak drill rehearsed. No secret ever touches your repo, your chat or your screenshots.
The routine
| Practice | Rule | Proof |
|---|---|---|
| Storage | Vault only, per environment | No secret string in code or images |
| Injection | Runtime, never baked | Staging boot log shows injection path |
| Scope | Least privilege per service | Access review with names, quarterly |
| Rotation | Dated schedule plus on-leave rotation | Rotation log with dates |
| Leak drill | Revoke, rotate, assess, notify | Drill record with a timer |
Worked example: the leaked demo key
A fictional demo (fictional) ships with a provider key in a slide deck. The drill runs: revoke in minutes, rotate, assess calls from logs, notify per the customer process. The demo continues on the rotated key the same day. Embarrassment survives; the system does too, because the drill existed. The containers post covers image hygiene; the permissions post covers scope.
Checklist: secrets hygiene
- Zero secrets in code, images, docs, chat or screenshots.
- Rotation dates on a calendar with an owner.
- Leak drill rehearsed once, timed.
- Exposure assessment uses logs, not guesses.
Related reading
Straight answers
Frequently asked questions
Where should secrets live?
In the customer's vault or secret manager, injected at runtime, scoped per environment. Never in code, images, docs or chat.
Who owns rotation?
The customer owns the schedule; you own the drill: rotate, verify, assess exposure, all rehearsed before any leak.
What happens after a leak?
Revoke, rotate, assess exposure from logs, notify per the customer process. The plan written before the leak decides whether it stays an incident.