End of the day, the secrets are being written to a .properties file or /proc/<pid>/env somewhere anyway and can be read by whomever has the permissions or the shellcode to do so..
End of the day, the secrets are being written to a .properties file or /proc/<pid>/env somewhere anyway and can be read by whomever has the permissions or the shellcode to do so..
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
Thanks for coming to my brain dump.
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.
edited to add "files"
The 3 of 5 keys thing is just a default and easily changed.