A short guide to secrets management

It comes up on almost every project, usually later than it should. Everything we would tell a client about secrets management in the time it takes to drink a coffee.

The bill is a design document: it tells you exactly what your architecture actually does. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

What is actually at stake

Secrets in a repository are a breach waiting for a schedule. Small and consistent beats large and occasional here. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

How to approach it

Rotate them on a cadence, not after an incident. That sounds obvious written down. It is still the thing most often skipped. Doing this properly once is usually cheaper than doing it approximately three times.

The mistakes we see most

Every secret should have a documented owner. None of that requires a large budget, only a decision and someone to own it. Doing this properly once is usually cheaper than doing it approximately three times.

In practice

Cloud work rewards teams who automate early and punishes teams who click through consoles. Three things worth confirming about secrets management before you move on:

• Someone can say what the current setup is without going to look
• Every secret should have a documented owner — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.