<p>I think you're misunderstanding what is considered bad practice.</p>

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

<p>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.</p>

<p>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 </p>

CC BY-SA 4.0
2020-02-28T03:44:29.847Z
2020-02-28T03:44:29.847Z
hvindin
<p>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.</p>

<p>Is this feasible? In Hashicorp's documentation for Vault, <a href="https://www.vaultproject.io/docs/configuration/storage/in-memory/" rel="nofollow noreferrer">the in-memory storage option</a> 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?</p>

CC BY-SA 4.0
2020-02-27T08:47:45.937Z
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
<hashicorp-vault>
Why not run a stateless Hashicorp Vault in production?
David
# Why not run a stateless Hashicorp Vault in production?

(Asked by: username_0 on 2020-02-26)

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](https://www.vaultproject.io/docs/configuration/storage/in-memory/) 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?

**Tags:** hashicorp-vault

> **Comments:**
> **username_1**: Hi username_0! 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.  

---

## 1 answers

### Answer by username_2 on 2020-02-28. Score: 1 | Accepted answer

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


---

