vault-operator
vault-operator copied to clipboard
Auto initialize vault
Vault should be auto initialized and the keys should be sent to aws kms. Either kube2iam be used to pass the aws credentials or accessKey/SecretKey pair can be used too.
Initial check should be made if vault was initialized before. If yes, then #308 or continue with init.
Wouldn't it be better to just store the unseal keys as a secret? Seems less cloud specific to do it that way.
I would like to have someone build a design doc on how we can do this based on kubelet identity and Kubernetes secrets instead of using kube2iam. This will ensure good security and generic application across cloud providers.
I'd be new to doing that, but can learn if you can point me to the existing document (if one exists) for using kube2iam.
It is new to me as well, I'm fine to contribute to the design(sample?).
I suggested kms because of the below reasons
- The keys would be stored encrypted whereas kubernetes secrets are not (afaik).
- For use cases where kubernetes etcd backend is not backed up as they dont store any state of the apps and can immediately rebuild their infra using terraform.
- If the kubernetes secrets are deleted by mistake, or the namespace is deleted, then there is no way to recover the keys and vault cannot be unsealed.
@philips do you have a rough outline the community could fill out?
Quickly thinking we could:
- kubelets generate PGP keys a. store private key locally(?) b. store public key as secret
- vault operator divides key into N parts encrypts it with the kubelet private keys and writes them to secrets
- vault operator deploys new "unlocker" daemonset to kubelets a. unlocker watches vault state, if its locked they... b. decrypt their key and sends it to unlock
- when a new node comes online we follow https://www.vaultproject.io/guides/operations/rekeying-and-rotating.html and rotate the stored keys
Please just consider this a conversation starter... 😃
Assuming Vault is in an HA state, would it be possible to store as kubernetes secrets as long as you have secrets encrypted? Secrets can be encrypted with Vault now: https://github.com/oracle/kubernetes-vault-kms-plugin/blob/master/README.md
That would make the initial bootstrapping step different from the 'normal case' which is dangerous in my experience.
Wouldn't the bootstrap process stay the same? It would just reinforce that an org using a KMS should be encrypting their kubernetes secrets.
It would stay the same in that it would still be manual