Open raoofm opened 6 years ago
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
@philips do you have a rough outline the community could fill out?
Quickly thinking we could:
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
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.