vault-operator icon indicating copy to clipboard operation
vault-operator copied to clipboard

Auto initialize vault

Open raoofm opened this issue 6 years ago • 9 comments

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.

raoofm avatar Apr 20 '18 19:04 raoofm

Wouldn't it be better to just store the unseal keys as a secret? Seems less cloud specific to do it that way.

thrawn997 avatar Apr 22 '18 05:04 thrawn997

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.

philips avatar Apr 23 '18 06:04 philips

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.

thrawn997 avatar Apr 23 '18 06:04 thrawn997

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.

raoofm avatar Apr 23 '18 16:04 raoofm

@philips do you have a rough outline the community could fill out?

Quickly thinking we could:

  1. kubelets generate PGP keys a. store private key locally(?) b. store public key as secret
  2. vault operator divides key into N parts encrypts it with the kubelet private keys and writes them to secrets
  3. 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
  4. 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... 😃

deedubs avatar Oct 01 '18 18:10 deedubs

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

thrawn997 avatar Oct 01 '18 19:10 thrawn997

That would make the initial bootstrapping step different from the 'normal case' which is dangerous in my experience.

deedubs avatar Oct 01 '18 19:10 deedubs

Wouldn't the bootstrap process stay the same? It would just reinforce that an org using a KMS should be encrypting their kubernetes secrets.

thrawn997 avatar Oct 01 '18 19:10 thrawn997

It would stay the same in that it would still be manual

deedubs avatar Oct 02 '18 13:10 deedubs