Secrets management: the questions we get asked most

This is cheap to get right at the start and expensive to retrofit. The questions about secrets management that come up most often on our calls.

Operability is a feature, and it has to be built rather than bought. Budget a little time for it every quarter and it never becomes a project of its own.

Do we need to care about this?

Secrets in a repository are a breach waiting for a schedule. None of that requires a large budget, only a decision and someone to own it. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. The reasoning matters more than the rule, because the rule has exceptions.

How do we know it is working?

Every secret should have a documented owner. In practice this is a scheduling problem more than a technical one. Doing this properly once is usually cheaper than doing it approximately three times.

The short version

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
• 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

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.