Hello best community,
I am planning to run a Kubernetes Cluster but on-premise and i don’t have KMS nor HSM to be used for Vault to enable Auto-Unsealing
While using the Auto-unseal using Transit Secrets Engine will trigger another issue is that we have to auto-unseal it as well as the primary main Vault cluster which seems to be a loop.
Is there any suggestion to be considered as a production grade in this matter ?
Thanks in advance
“Production grade” would probably be to use the HSM option from Enterprise Vault. Otherwise take a look at the manual unseal option (maybe in addition to the transit auto-unlock)
Production grade means you have to look very hard at your requirements and threat models, because it doesn’t mean the same for everyone.
Need good protection against single bad actors, and only care about Vault uptime in core business hours? Then Shamir seal and keyholders manually unsealing Vault might actually be a good option.
Need 24x7 unseal capability, running in a public cloud environment - and, the bits everyone always forgets about - have complete trust that your public cloud administrative credentials are appropriately secured against bad actors, AND willing to accept that even your backups are unusable without cloud keys? Then and only then, public cloud KMS auto unseal might be good.
Running on-premise in Kubernetes? Well, depending on how much you trust the hardening and administration of your Kubernetes cluster, it might be OK to just stick the unseal key in a Kubernetes secret. It’s a relatively low tech solution, true, but bear in mind that any auto-unseal method means a Vault process needs to be able to authenticate itself to a service or HSM… how will it get the credentials to do that? Will they themselves be something an attacker can also obtain, if they are in the position to compromise the Kubernetes cluster? Will any extra layer of abstraction you create here increase your security? (It might - for example, even if you can’t make it any harder for an attacker to get the unseal key, it might still make it easier to detect them doing so, if it needs to be fetched from another system for each use.)
This is why it is important to start by defining what threats you need and want to protect against, and how much time and money you’re willing to spend doing so - because any solution that is balancing security vs. ease of access to the unseal key at any time, is always going to require a degree of trading off one to achieve the other.
As stated in the question is not related to threat modeling, The thing is the auto-unsealing without having something like KMS.
and i was looking for a “production grade” in that matter.
There is the HSM option via Enterprise Vault. Alternatively there is the transit auto-unseal option, which in turn could be manually unsealed or connected to a cloud (e.g. AWS KMS) for auto-unsealing.
the transit auto-unseal will require manual action too which we don’t need to do from the original Vault 
if we have KMS we will not create transit auto-unseal 
In which case the HSM options seems to be the one remaining.
Which part of the transit auto-unseal requires manual action?
I want to automate the unseal process because vault pods restart in sealed mode.
I am just starting to explore this option for my production environment and don’t want hit any roadblocks.
Is there any doc or tutorial that has steps to auto-unseal using kubenetes secrets?