search

hashicorp / vault-k8s

First-class support for Vault and Kubernetes.
Mozilla Public License 2.0
789 stars 170 forks source link

enable VAULT_CONFIG to be injected into all containers #232

Open sjpotter opened 3 years ago

sjpotter commented 3 years ago

Is your feature request related to a problem? Please describe.

We have a kubernetes operator that we are using with vault. Becaues our custom resource use random secrets (i.e. specified in the custom resource) we can't have the injector inject them into the container, but have to build a vault client that retrieves them.

In order to build a vault client, one has to know certain information (notably vault server address, ca cert and token to use, or how to get a token).

We use the vault injector to manage the token's lifecycle for us, so all we need is the address and ca cert. While we can inject the ca cert (if we control the annotations to our operator) to a known location, we can't easily inject the vault server's address unless we actually know it. What we would like is for VAULT_CONFIG to be injected into every container (or at least boolean configurable) so that this information is made available to us. This would have the side effect of us not needing to know how our clients want to set the ca cert secret key name, as they could just specify it as an annotation and it would be stored in the VAULT_CONFIG env.

Describe the solution you'd like

enable VAULT_CONFIG (i.e. the base64 json version of agent.Config struct) to be injected into every container.

Describe alternatives you've considered

we currently require them to be specified as environment variables that are manually edited in to each deployment. This is ugly.

jasonodonnell commented 3 years ago

Hi @sjpotter, this is an interesting request. The agent injector actually generates the config, so if you want specific values set on your containers, it would probably be more efficient to just set those (VAULT_ADDR for example). Thoughts?

sjpotter commented 3 years ago

We are setting them by hand right now, but it seems a waste when the agent injector is already running and knows all this information, but isn't injecting those values into our container, its just injecting the secret/token we ask for in our annotations (we are just using it to inject the token, so we don't have to manage its lifecycle and the actual secret reading is done by own go code).

essentially, its not as nice experience to create a vault client within a pod that the injector is already running on as it should be.

For Kubernetes, all I have to do is use go-client and it can tell if I'm running in a pod, if env variables are set or if ~/.kube/config exists and it ends up being transparent to the end user. Vault is much more annoying to code against. When I saw the VAULT_CONFIG I was like "yes, this is what I need". only to find out its not injected where I need it.