Ideas
Security sets the rule, operations runs it
Governing secrets takes two roles that work closely together and never merge: security writes the policy, operations runs the tool, and both choose it together
When an organisation picks a secrets manager, the debate is about the tool: Vault, a cloud service, whatever the pipeline already offers. In the review of secrets managers I presented this spring, comparing the tools was only one part. The last section was about governance, because governance is what makes the rollout succeed.
First, the scope. A secret is not necessarily a password: credentials, encryption keys, private keys and certificates, service-to-service tokens, any sensitive data counts. And from development to production, several people with different levels of access handle it.
Then, two roles.
Security defines and maintains the policies. It manages access and authorisations, sets how often each type of key is rotated, decides how the unseal keys are distributed and stored, and decides when to revoke the root token: Vault advises doing so as soon as it is no longer needed.
Operations sets up and deploys the tool, runs and monitors it, automates access and authorisations, and keeps improving it.
Both take part in choosing the tool, and two links hold them together: collaboration and communication.
Security writes the rule. Operations makes it happen every day, without anyone having to ask
Why not merge them? When security also runs the platform, every access becomes a request to a team that is not built to automate, and the other teams end up working around it. When operations also writes the rules, the rotation frequency drifts towards what is easy to automate, and whoever holds the keys decides how they are kept. Either way, the separation the tool was meant to guarantee dissolves inside the team that runs it.
The test, before choosing any tool: for each line of the policy, name who writes it and who applies it. If the same name appears on both sides, start there.