I don’t know if I’ve just missed it or if it’s not supported, but I’m using the k8s vault-agent-inject connected to an external vault server with self-signed https. With a normal vault-agent, I’d be able to specify a ca_cert in the config or a VAULT_CACERT environment variable. But I can’t see a way to pass any of this information to vault-agent or vault-agent-init containers that get injected into a pod so I get the expected “x509: certificate signed by unknown authority” error. Is there a way to get a ca cert to those containers?
Hi,
I started trying out vault a week ago and I have been reading non-stop trying to make this work. I’m not sure if you mean external vault-server as of outside k8s and if so, these might not work. But I managed to get the secrets injected into a pod in two ways.
- I created a secret in the apps namespace in the same way as I created a secret for the vault server with the certificate. Then I asked for it with annotations. They get mounted under /vault/tls. You can read more about it here: https://www.vaultproject.io/docs/platform/k8s/injector/examples#patching-existing-pods
- vault.hashicorp.com/tls-secret: “client-vault-auth”
- vault.hashicorp.com/ca-cert: “/vault/tls/client.ca”
- I just found this on a medium blog and it also worked and I didn’t need to create anything extra.
- vault.hashicorp.com/ca-cert: “/run/secrets/kubernetes.io/serviceaccount/ca.crt”
I’m struggling to find out which way is best and most secure but my knowledge is still limited. If anyone else know any other way or have any comments on this. Please do so.
Same boat here.
DId you figure it out Aslev ?
Are you using the this annotation ?
http://vault.hashicorp.com/ca-cert: “/run/secrets/kubernetes.io/serviceaccount/ca.crt”
Sadly no. In my case I needed the secret to be injected as an environment variable, and as far as I understood, that isn’t(or wasn’t) supported or I couldn’t figure it out. So I moved on. I ended up using sealed-secrets instead.
I think the agent can use the OS cert store, can you add your self-signed cert into your container and try that?
Also… It isn’t the most elegant solution, you can get env vars set into Kubernetes with this
Ah yes, very true! I forgot about the sidecar injector. Sorry about that. In my case, did try it on the container that I wanted to run but the injector messed up the start sequence of the pod which in return forced me to enter the pod every time it got re-scheduled and start the application manually. Not very elegant as you put it.
If I put more effort into it, I could probably have solved it but this was just for a home lab.