1

I'm contemplating whether to provision Hashicorp Vault from code, from scratch, and seed it with keys to be shared between a few, predefined consumers (some humans, some services). The provisioning step has secure access to keys already and can use them to initialize Vault. My reasoning is that this would make it operationally simpler to run -- no backups or risk of configuration drift -- and can act as an on-ramp to using Vault in more places.

Is this feasible? In Hashicorp's documentation for Vault, the in-memory storage option is not recommended for production use because the data will be lost on shutdown. Is there data that is lost that can't be re-provisioned every time?

Improve this question
1
  • Hi David! Interesting question, but - you still need to store and maintain the secrets somewhere safe, and Vault is the place where you should do this. So, I would say what you propose is not a good practice in the long term, but perhaps it could be useful to convince necessary people in the interim. – Bruce Becker Feb 27 '20 at 8:47
1

I think you're misunderstanding what is considered bad practice.

Running vault with an in memory backend and being able to spin it up and provision it is fine. What is Not Fine is seeding the secrets in Vault from an insecure source.

If you are just using Vault as a way to simplify operations, as opposed to a long term persistent state store - then go for it.

One caveat - if you use the capabilities in vault to rotate keys for other integrated services then if you lose your vault cluster then you have just lost the keys to those services, so hopefully anything accessed using a Vault managed, regularly rotated, key is also easy for you to reprovision 🙂

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.