Sep 7, 2018 · 2 min read
Thanks for the post!
I have been pondering this space a bit but certainly haven’t put as much hands on keyboard time to accomplish something similar. One of the options I was pondering was trying to write a https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#encrypting-your-data-with-the-kms-provider that could “talk Vault”.
Curious if you had played with something in that space.
The goals I was hoping to accomplish were:
- Continue to use
kind: Secretin Pod specifications to keep things simple for our users. - Reduce some of the boilerplate of Vault integration (your webhook to a certain degree removes this boilerplate as well) that the sidecar or
initContainerwould require - Leverage Vault for dynamic or transit backends as the credential provider/encryptor
The idea I was considering was:
- The entities in the
datablock of the Secret could have a specific format ex:k8-vault://<dynamic backend path>/<secret>that the custom encryption provider could parse - On Encryption: If the entity has
k8-vault://this is a simple “pass through” that is saved as the contents of ETC-D - On Decryption: If the entity has
k8-vault://then we would query Vault for the “real” credential to be passed through to the underlying Pod - On Encryption/Decryption: If the entity does not have the
k8-vault://prefix we could either use thetransitbackend to encrypt/decrypt or simply pass through to ETC-D as it would have if we hadn’t implemented/configured a KMS provider
A few limitations I was seeing:
- Would need to ensure there was no caching for our custom KMS provider would
- The “Contract” for the service’s encryption/decryption does not actually provide Pod or Service Account level information, we loose the ability to provide strong auditing/RBAC on the Vault side of things https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.proto#L31
