Hi ,
I am trying to install vault on the on-premise server using docker-compose with file storage backend. Is there a way i could auto unseal vault with this setup.
You don’t need to run on the cloud to use a cloud provider to auto-unseal.
Yeah go it. But want to use an on-premise approach to auto unseal.
You can add a secondary vault on-premise, and use that one to unseal your primary vault using the transit auto-unseal setup.
But you’ll still need to unseal that secondary one somehow…
I’m about to start experimenting with that kind of setup myself.
1 Like
You can also use a HSM with the Enterprise version of Vault.
I thought of a solution.
We have docker compose file and it has two services , one the vault and other the python service which depends on vault service.
This python service checks if the unseal keys exists in a particular file(i.e keys file) in the container (i.e This is a bind mount to the host dir) and if it exists it uses this file as source to unseal vault . if the keys file doesn’t exists(i.e This happens only the first time) then it initialises vault and save the keys in the container. As the folder in which the keys are stored inside the container is a bind mount, the keys exist in host file system.
Now if vault is restarted, then Python container runs since the file exists, it uses this file to unseal vault.
Just initialises the vault and saves the keys in a particular directory in the container which is a mapped to a host container.
The only supported solution for on-site auto-unseal is another vault instance with the transit engine – AFAIK.
If your solution works for you great, but do keep in mind that the “entire” point of vault is keeping your secrets secret, and the unseal keys are how you secure that data. By putting your unseal keys in another container and in once place completely defeats the entire purpose of using Vault in the first place. Might as well just use a simple K/V API service, it’s probably 100 lines of code.
Gotta disagree with that. You’re right that it’s not a supported solution, and it does severely reduce the security that you get out of using shamir keys… But there are still benefits to using vault.
But just using a K/V api doesn’t afford you the permissions you could introduce with properly managed and distributed containers.
You could even set this up so that you have a separate container for each shard, distribute them across multiple hosts, and configure permissions on each one so that no single user can access all of them at the end of the day.
It’s not perfect, it’s not supported, but it is pragmatic.
Actually, i will be saving the files unseal keys file encrypted on the os.
This would be highly not recommended. Unseal keys belong separated and secured.
Do you plan to run a production Vault cluster/instance in docker-compose?
Yes but its not a cluster, only a single node raft integrated storage as backend.
Even I am facing a similar solution issue when we maintain a vault instance on-prem. Auto unseal, securing the shared secrets is challenging. Can I know your suggestions on this topic? I am thinking to store the vault unseal secrets as part of Docker and giving permission to custom service, which can access the unseal key for autounsealing the Vault. Simillar concept what you have mentioned in your previous chat.