Support token.metadata.<key> in ACL templates

[remilapeyre]

We have a Vault Enterprise client that is using Sentinel for two
applications. What they need to do with Sentinel is quite simple and
could be done much more easily by using ACL templates if they supported
injecting a token's metadata. That would be more readable than a large
Sentinel script and make it much easier to onboard operators that need
to make changes to those applications.

[ncabatoff]

Hi Remi,

We've had to say "no" to template-token-metadata requests many times I'm afraid, most recently in #10682. Excerpted:

We view this change as dangerous, since a user can create child tokens with whatever arbitrary metadata they like. This means policy templating using token metadata is vulnerable to any attacker who's aware of what policies are in use. I expect that you could come up with safeguards in your environment to protect against this (e.g. not granting access to the create token endpoints), but we as vault devs have to be vigilant against introducing features that allow for insecure by default behaviour.

Can you use identity metadata instead for your use case?

[remilapeyre]

We view this change as dangerous, since a user can create child tokens with whatever arbitrary metadata they like.

Wow, indeed I completely missed this. I suppose implementing this feature like this is a no go then.

Can you use identity metadata instead for your use case?

In our case we can't use entities because of the way Vault Enterprise is priced, doing this would add thousands of entities.

Perhaps their could be some way to do this by adding a new field to TokenEntry that would not suffer the same issue and be inherited when creating a child token, let's call it attributes as an example.

Just like you need to be root to set orphan on auth/token/create, you would need to be root to set this new attribute.
This new attribute would always be copied verbatim to child tokens, only root could overwrite it.

In auth/token/roles/:role_name there could be a new allow_custom_attributes that would make it possible for a non-root application to generate tokens with the data it needs.

This could make this feature work, root would be able to create tokens with whatever attributes it wants, normal users would not be able to add or remove entries in attributes by creating child token as it would always be copied and applications needing special rights to generate token with custom attributes could do it by using a token role.

It seems to me that this could be secure, after all an application that can make changes to auth/token/roles/:role_name can already get full access to Vault by choosing the permission they get and generate root tokens.

If you think that it's worth it to try something like that I can propose a better patch to explore things out and fix the shortcomings of this one, otherwise we can close this PR.

[UXabre]

Sorry for replying on an older PR but I was browsing to see if others came up with new insights in the subject.

I'll go ahead and link this topic as I think it offers a similar solution as what you describe. TL;DR just as you propose, we need to "prove" the data to be authorative and not "arbitrary".

[mladlow]

Hey @remilapeyre ,

We discussed this a little more internally. Identity metadata should allow users to template ACL policies while using a unique identity for each application, service, or user that needs to authenticate to a cluster. At this time we don't want to add a new mechanism for ACL templating.

[celesteking]

Wow, indeed I completely missed this. I suppose implementing this feature like this is a no go then.

It's not your fault, it's Hashicorp's and they don't want to admit the mistake.