Justin Nauman
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: Secret in 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 initContainer would require
  • Leverage Vault for dynamic or transit backends as the credential provider/encryptor

The idea I was considering was:

  • The entities in the data block 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 the transit backend 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:

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade