Promote Alias Metadata to Entity Level

[typesafe]

I would like to configure all my K8S Service Accounts with a single Policy Template and Role, but I'm stuck because the service account metadata is only available/stored at the alias level, not at the entity level.

Here's a brief description of my full setup to give you some context:

• k8s auth plugin enabled -> works just fine
• vault secrets "kv" enabled on path secrets -> OK
• our application/system is split up in modules that consist of one or more K8S workloads
• every module has its own dedicated k8s service account (which is assigned to all workloads of that module)
• the name of the service account reflects the name of the module, for example "party-management" or "accounting"
• in our "ecosystem" of modules we have 2 types of secrets:
  • shared secrets that can be access by all modules (and its workloads): stored in secrets/shared/*
  • private secrets, only accessible to a certain module (and its workloads): stored in secrets/<MODULE_NAME>/*

With a single policy template (e.g. "k8s-workload-policy") that looks like this:

path "secrets/shared/*" {
  capabilities = ["read", "list"]
}
path "secrets/{{identity.entity.metadata.service_account_name}}/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

Notice the {{identity.entity.metadata.service_account_name}} that references the service account name, which corresponds to the module.

And a single role (per k8s namespace):

vault write auth/kubernetes/role/k8s-workload \
  bound_service_account_names=* \
  bound_service_account_namespaces=<NAMESPACE> \
  policies=k8s-workload-policy \
  ttl=6h

I could give all my workloads access to the relevant secrets by exchanging their (automatically) mounted k8s service account JWT for a Vault token that is linked to the policy.

Unfortunately, this is not possible because the metadata of the service account is only stored on the alias which I can't reference in the template because its key is a GUID, e.g. the mount_accessor I should have to specify in {{identity.entity.aliases.<<mount accessor>>.metadata.service_account_name}}...

I'm not sure how other auth plugins deal with aliases, but certainly in case of the kubernetes auth plugin I think it is perfectly fine to propagate the metadata from the alias level to the entity level. This could easily be done by setting it on the entity instance created here:

vault/vault/identity_store.go

Line 461 in c80bd1b

entity = new(identity.Entity)

As far as I can tell, there is a one-to-one mapping of alias and entity in this (k8s) case, but I don't know Vault good enough to know if I'm correct on this.

In case other plugins would run into trouble with this propagation of meta data, we could let the plugin decide what values to promote?

I'd be happy to submit a PR for this, if it seams like a reasonable thing to do...

[jefferai]

Alias metadata is supplied by the authentication plugin. Propagating alias metadata to the entity level risks it becoming out of date or colliding with other aliases.

Given that the mount accessor UID is constant I must admit I'm not really understanding the issue here.

[typesafe]

Aha! Looking at other examples, I always saw GUID values being used as the mount accessor value. This must have biased my train of thought, causing me to mistakenly take the alias ID (which was a GUID) as the mount accessor, but it's actually auth_kubernetes_a47bdad1 (the auth method, of course...)! This is my first hands-on experience with Vault, still learning :-).

Awesome, thanks for pointing this out!