while reading information about auto-unsealing a Vault, I came up with (yet) another way of auto-unsealing a Vault
My Vault instance is running on an offline Kubernetes cluster, hence ruling out the Cloud based auto-unseal options.
The Transit Auto Unseal method didn’t make too much sense, because it uses one Vault to unseal the other…
Unfortunately the unsealing Vault itself needs to get unsealed itself at startup, so that stll wasn’t a fully
automated way of unsealing Vault.
I found this : How to automatically unseal Vault Server for free · Omegion: Personal Blog
but that method stores the unseal secrets in the kubernetes configuration so cluster admins
still have access.
So I had to think of something, and this is my idea :
A dedicated server is running a HTTP(S) server process that listens for incoming POST requests.
The POST arguments contain the pod’s service account token ( from ‘/var/run/secrets/kubernetes.io/serviceaccount/token’ )
and some string identifying the Vault’s instance, like the Vault cluster URL ( e.q. my-vault.mycluster.mydomain )
so it can lookup unseal keys for multiple vaults, if desired.
The listener has access to the unseal key thru a file protected by OS ACL’s, and has the Kubernetes CLI in it’s PATH.
On incoming POST requests it can now use the serviceaccount token for kubernetes CLI cluster-login, and
then issue a ‘kubectl exec -ti -n – vault operator unseal <UNSEAL_KEY>’.
The serviceaccount therefore needs an additional role-binding that grants “create” on resource “pods/exec”.
The last step is to have the pods call the unseal server POST endpoint by the ‘curl’ command at startup,
by using the ‘postStart’ pod lifecycle handler.
My Vault has just one shard configured, so my implementation is not too complex.
I implemented the listener in Python, and everything works fine. It uses a dedicated kubeconfig for
Just wanted to share this here, and I’m aware that it has some security tradeoffs. If anyone is interested, let me know and I help you out on the details.
Have a nice day !