-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support vault cacert bytes env #507
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything looks great, I had just a question around whether or not we should require b64 encoding of the field?
CACert string | ||
|
||
// CACertBytes is the contents of the CA certificate to trust | ||
// for TLS with Vault as a PEM-encoded certificate or bundle. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this expected to be b64 encoded? Should we specify one way or another?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be PEM-encoded or base64. I added some comments in d50e787 to document the optional base64 encoding.
if a.Vault.CACertBytes != "" { | ||
envs = append(envs, corev1.EnvVar{ | ||
Name: "VAULT_CACERT_BYTES", | ||
Value: decodeIfBase64(a.Vault.CACertBytes), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess going back to my previous comment, is there any reason not to make b64 encoding a requirement? The formatting of certs with all their carriage returns is to me frustrating at best trying to get into string values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the benefit of making b64 required. Supporting the raw PEM is nice because it's how the environment variable is eventually consumed anyway, and supporting b64 is nice because as you say it can be frustrating when there are multiple levels of interpretation in the automation that gets the value into place.
I think vault has a dev-tls mode now that generates its own certs, might able to use that instead of cert-manager, if we can copy the generated cert out of the vault container.
|
I considered this before but didn't give it a fair shot because of the fact it would require a multi-stage Vault helm chart rollout. One part to get Vault and its certificate, and then another part to give those certificate details to the injector. I had a more serious go anyway in c8fc7ff, and it's actually a really nice simplification overall. Unfortunately though,
We can get around it by setting |
Vault v1.14.2 should have full support for |
Hello, |
Thanks for the reminder @M0NsTeRRR - I just pushed a few updates that take advantage of Vault updates in 1.14.2 and 1.15.0. There should be a release of both Vault and vault-helm pretty soon, at which point I can remove the version pinning from dev.values.yaml and this should be ready to land. @tvoran @kschoche, the updates are non-trivial so you may want to have another scan, but nothing we haven't already discussed in the PR feedback. The only remaining change I'm planning to make before merging is to get rid of the version pinning in dev.values.yaml. |
Actually, we'll also be releasing vault-k8s soon, and it would be nice to get this change into that release, so perhaps I won't wait for the vault-helm release, but instead just give @tvoran and @kschoche a chance to have another pass at reviewing. I'll back out the version pinning in a separate PR after all the releases are done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worked great for me testing locally. Would you mind updating the PR description since I think it's changed a bit since its original incarnation? And a changelog entry as well.
(still) Looks good to me, I like the approach! 👍🏽 |
Thanks for the reviews!
Thanks for the reminder, done 👍 |
This builds on #446 to support setting CA certificates for injected pods, but uses
VAULT_CACERT_BYTES
instead of writing files. It turned out Vault Agent's auto-auth already supported that env var but templating did not because consul-template hadn't implemented it yet. This was fixed in Vault 1.14.2 and 1.15.0, via hashicorp/vault#22322. Vault 1.15.0 also added the-dev-tls-san
flag via hashicorp/vault#22657 which lets us easily test with self-signed certificates.To test and teardown locally, use
make image deploy exercise teardown
in a localkind
cluster. I added that workflow to CI as well to make sure any breakages are found quickly.