Allow annotating service accounts with arbitrary tags for policy templating

[dovys]

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.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: example-account
  namespace: default
  annotations:
    auth-metadata.vault.hashicorp.com/service-role: example-value

Which you can then use in policies as so

{{identity.entity.aliases.${vault_auth_backend.kubernetes.accessor}.metadata.service_role}}

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 so service.profile is not allowed to obtain certificates for service.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

• [ ] TBD Add relevant docs to upstream Vault repository, or sufficient reasoning why docs won’t be added yet My Docs PR Link Example
• [x] Add output for any tests not ran in CI to the PR description (eg, acceptance tests)
• [x] Backwards compatible

[hashicorp-cla]

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.

• [x] dovys
• [x] chongyangshi
• [ ] nickrmc83
• [ ] Dovydas Bartkevicius

---

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.}

[tomhjp]

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.

[CodyKurtz]

Is there an update on this?

[CodyKurtz]

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

[thyton]

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.