Allow annotating service accounts with arbitrary tags for policy templating #132
Conversation
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. ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: example-account namespace: default annotations: vault.hashicorp.com/auth-metadata/service-role: example-value ``` Should allow us to use in policies as so ``` {{identity.entity.aliases.${vault_auth_backend.kubernetes.accessor}.metadata.service_role}} ``` 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 al so introduce another roundtrip to the Kubernetes API, however we are using a pooled tcp client so hopefully not too many new open connections.
…t have multiple subpaths
Co-authored-by: Chongyang Shi <[email protected]>
Add support for using serviceaccount annotations
|
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. Have you signed the CLA already but the status is still pending? Recheck it. |
Run go fmt for last change
|
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? |
Any updates on this? Thank you |
With K8S 1.21 bound tokens are now the default which have the name and namespaces in a different location. The wrapper functions take care of picking out the correct function automatically.
Use `namespace()` and `name()` wrapper functions
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_annotationsso 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.profileis 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
My Docs PR Link
Example