Token metadata support for policy template

[iamlothian]

Is your feature request related to a problem? Please describe.
I have a number of microservices that use vault to access configuration secrets, and each has an orphaned token generated for it using a specific role that defines policies for access to applications specific config secrets.

application-config-secrets

path "secret/{{token.metadata.service}}/{{token.metadata.environment}}/*" {
  capabilities = ["read"]
}

app-config

curl --location --request POST 'http:https://localhost:8200/v1/auth/token/roles/app-config' \
--header 'X-Vault-Token: s.' \
--header 'Content-Type: application/json' \
--data-raw '{
  "allowed_policies": ["default","application-config-secrets","application-credentials-storage"],
  "orphan": true,
  "renewable": false,
  "token_type": "service",
  "token_explicit_max_ttl": 0
}'

Create token Token

curl --location --request POST 'http:https://localhost:8200/v1/auth/token/create/app-config' \
--header 'X-Vault-Token: s.' \
--header 'Content-Type: application/json' \
--data-raw '{
    "ttl": "0",
    "meta": {
        "environment": "local",
        "service": "service-name"
    }
}'

Request to retrieve secret

curl --location --request GET 'http:https://localhost:8200/v1/secret/service-name/local/datasource' \
--header 'X-Vault-Token: s.'

Describe the solution you'd like
I'd like to be able to interpolate the token's metadata in my policy to simplify ACL policy management

Describe alternatives you've considered
Without this each service will require an explicit policy to limit access to it's own secrets and the solution become far less generic to manage.

[ncabatoff]

Hi @iamlothian,

I won't rule out the possibility that we implement this at some point. In the meantime however, I think you can achieve the result you're aiming for by creating an entity and alias for each role that needs distinct policies, put the metadata into the entity, and bind the entity alias to the token role.

[ncabatoff]

Actually, we've discussed this more internally, and we've decided we don't want to do this. The entity-alias solution is the right way to handle this. Allowing non-entity tokens to have interpolatable metadata would complicate some of our 1.9 work. Sorry about that!