If you're just storing secrets as static key/value, sure.

Vault's real value is in rotating credentials automatically. Some of that value has eroded over time, e.g. Kubernetes now having IAM Roles for Service Accounts. But Vault handles it for databases, and there are a variety of plugins to handle it for other usecases as well, e.g. https://github.com/martinbaillie/vault-plugin-secrets-github

I have been curious about this, too. I think I'd want something like vault to issue OTPs that can be exchanged for secrets over a socket to a sidecar, where the OTP is made available as an environment variable set by the orchestrator (eg k8s). If the token is used twice, lock it all down. If it's read but not confirmed to have been received by the service (through some method... dunno), lock it down.

Thanks for coming to my brain dump.

If you don’t need the Shamir part of Vault, create fewer key shares.

If you integrate properly throughout the stack (i.e “not being negligent”) then secrets will not hit properties files, rotation will happen correctly, and you will be able to audit everything.

You can also do this using a native secret management system if you’re in a a public cloud, but Vault is, for the most part, just better.

With its PKI endpoint, it makes it pretty easy to stand up an internal CA. No faffing about with arcane openssl commands.

The 3 of 5 keys thing is just a default and easily changed.

Set to autouseal with a transit or cloud (or hms if you pay them $$$) and you don’t need to use sss unless to recover root token (or if somebody leaves)