When secrets management is worth the effort

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. Secrets management is not free, and pretending otherwise leads to bad decisions.

The bill is a design document: it tells you exactly what your architecture actually does. It is the sort of thing that looks like polish right up until it costs you an enquiry.

When it is worth it

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. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. None of that requires a large budget, only a decision and someone to own it.

How to decide

Every secret should have a documented owner. Getting it slightly wrong is survivable. Ignoring it entirely is not. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

In practice

Operability is a feature, and it has to be built rather than bought. 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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.