How to get secrets management right
Every audit we run turns up some version of this. The short answer to secrets management is that it is mostly a sequence of small decisions, not one big one.
Cloud work rewards teams who automate early and punishes teams who click through consoles. It rarely shows up as a line item, which is exactly why it slips.
What is actually at stake
Secrets in a repository are a breach waiting for a schedule. The reasoning matters more than the rule, because the rule has exceptions. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
The steps
- Establish what you have today before changing anything
- Rotate them on a cadence, not after an incident
- Every secret should have a documented owner
- Write down the decision so the next person does not re-litigate it
Every secret should have a documented owner. It is worth being explicit about, because assumptions differ quietly. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
Turning this into a decision
What this looks like day to day
The bill is a design document: it tells you exactly what your architecture actually does. Three things worth confirming about secrets management before you move on:
- Someone can say what the current setup is without going to look
- Secrets in a repository are a breach waiting for a schedule — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you want a second opinion on how yours is set up, ask.