Add go templating to Identity Policy Templating

[maxramqvist]

Is your feature request related to a problem? Please describe.

We are using the Azure auth plugin with Vault and policy templates based on the values from {{ identity.entity.metadata.}}. Like this example:

path "kv/data/services/{{ identity.entity.aliases.<mount accessor>.metadata.resource_group_name }}/*" {
  capabilities = ["read"]

Our resource group example is called consul.

Our configuration scripts can log in to Vault and access the secrets stored in the expected area in Vaults K/V. Possible example:

kv/data/services/consul/really_important_stuff

The problem is when changing details on a machine in this resourcegroup with the Azure CLI, or some Azure APIs, Azure manipulates the resource group name, setting the name of the resource group to uppercase.

Vault will now, as should be, only allow access to:

kv/data/services/CONSUL/really_important_stuff

Which of course means failing to get really_important_stuff that is needed for the configuration of the Consul servers.

This is apparently a known problem with Azure, mentioned multiple times over the years, since 2017 at least.

https://github.com/Azure/azure-powershell/issues/9891 https://github.com/Azure/azure-sdk-for-java/issues/1708 https://github.com/Azure/azure-sdk-for-java/issues/1508

There are more of course...

Describe the solution you'd like Allow me to use templating in the policy definitons like this:

path "kv/data/services/{{ identity.entity.aliases.<mount accessor>.metadata.resource_group_name | tolower }}/*" {
  capabilities = ["read"]

The templates are used in multiple places in configuration of different secrets backends and such. Code is already available here: https://github.com/hashicorp/vault/blob/master/sdk/helper/template/funcs.go

Describe alternatives you've considered Enrich vault-plugin-auth-azure with metadata from the Azure tags of the entity authenticating, that way we could use the tags for this and wouldn't have to use templating functions. I still think that would be a nice feature though...

Explain any additional use-cases Any time the backend system doesn't work as expected this would be helpful, as mentioned its already used at multiple places in Vault.

[erickufrin-okta]

agreed. case sensitivity issues can complicate policy templating to the point where its unusable.

i had a similar issue with a CamelCase OIDC backend where luckily I was able to use a similar function to force all lowercase prior to mapping it into Vault.

[peter-fe]

Just another use case that would benefit from having go templating available like in other places (e.g.: Username Templating)

We like to use JWT auth (via Github-Action Vault-Action) in combination with policy path templates, but the claim we are interested in, to use in the template contains a "/" (actually the "repository" claim consists of <org>/<repo>) which is supported by the simple KV engine (forming a sub path), but not in the GCP secret engines, where we like to fetch short lived tokens for our workflows.

If we could do something like this:

path "gcp/impersonated-account/{{ identity.entity.aliases.$ACCESSOR.metadata.repository | replace / _ }}/token" { capabilities = ["read"] }

Would be a perfect solution, keeping the information from the claim and not being limited by unsupported characters.

In our case (GitHub Actions), adjusting the claim itself is not supported, so actually blocking the use of policy templating, forcing us to create dedicated policies for every token/secret we want to access.

[naxim92]

Another example if I want to use metadata.role (which is accessable in Vault 1.16) string as part of a path I need to modify it (cut, etc)