Closed dovys closed 8 months ago
Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement
Learn more about why HashiCorp requires a CLA and what the CLA includes
2 out of 4 committers have signed the CLA.
Dovydas Bartkevicius seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you already have a GitHub account, please add the email address used for this commit to your account.
Have you signed the CLA already but the status is still pending? Recheck it.
Hi @dovys, thanks for raising this! I'm going to gather some feedback internally on the feature, and I'll get back to you as soon as I can.
Is there an update on this?
Hi @dovys, thanks for raising this! I'm going to gather some feedback internally on the feature, and I'll get back to you as soon as I can.
Any updates on this? Thank you
Thank you for your contribution, @dovys! We started a fresh PR https://github.com/hashicorp/vault-plugin-auth-kubernetes/pull/226 taking inspiration from this one. We're going to close your PR.
Addresses hashicorp#85
We took Mark's proposed design and added support for defining annotations on service accounts that can later on be used in policy templating.
Which you can then use in policies as so
Who the change affects or is for (stakeholders)? The change is behind a config flag called
enable_custom_metadata_from_annotations
so it should not affect any of the existing integrations. In order to enable the flag users will have to update the clusterrole and allow Vault to read service accounts. If this change is accepted we'll open PRs to update various docs, terraform providers, etc. This will also introduce another roundtrip to the Kubernetes API, however we are using a pooled tcp client so hopefully not too many new open connections.Why is the change needed? At @monzo we want to use fully qualified service names for certificates issued under Vault's PKI, ie
service.profile
. At the same time we want policies and roles to be very strict soservice.profile
is not allowed to obtain certificates forservice.id
. As we have over 2000 microservices and they grow at a steady rate it's not feasible to write a new policy for each. Allowing us to annotate service accounts with the fully qualified service name and then use it in PKI mount allowed_domains with templating solves this issue.Design of Change
We've largely adhered to the current code style present in the repo. All changes are behind a config flag
enable_custom_metadata_from_annotations
. Existing integrations are not affected until the flag is turned on.Related Issues/Pull Requests
TBD - we'll create PRs for the terraform provider and docs when this PR has been largely agreed upon
Contributor Checklist