New Templating Parameters for approle/ldap Auth Methods

[lcgkm]

How to write the templated ACL policies for AppRole?
Current Available Templating Parameters don't have role_name...
https://www.vaultproject.io/guides/identity/policy-templating.html

For approle token, we can find following info:
token_meta_role_name=<<approle name>>

For ldap token, we can find following info:
token_meta_username=<<ldap username>>

So, can we use token meta data as policy templating parameter? For example:
token.metadata.<<metadata key>>

Reference:
https://learn.hashicorp.com/vault/identity-access-management/policy-templating#available-templating-parameters

[chrishoffman]

Token metadata will likely not be added to the available template parameters. For both of the use cases above, you can leverage the identity system. Each AppRole will create an entity in the identity system with a mapping to the role id. LDAP has a mapping to the username.

Check out these guides for more information:
https://learn.hashicorp.com/vault/identity-access-management/iam-identity
https://learn.hashicorp.com/vault/identity-access-management/policy-templating

[lcgkm]

Hi @chrishoffman ,

Sorry for bother you.

Each AppRole will create an entity in the identity system with a mapping to the role id.

Could you provide more details about this? How about the entity lifecycle?
And I can find that AppRole will create an entity and entity alias in identity system, the entity alias's name as same as the AppRole's role id.

identity.entity.aliases.auth_approle_5e196f43.name=AppRole's role id

But how about AppRole's role name?
Can vault auto add AppRole's role name to entity alias meta? like:

identity.entity.aliases.auth_approle_5e196f43.metadata.role_name=AppRole's role name

Best Regards,
CG Li

[sielaq]

@chrishoffman can you elaborate why "Token metadata will likely not be added" ?
the mapping between approle vs token is in token's metadata

having path like

path "secrets/{{token.meta.role_name}}" {
    capabilities = ["read"]
}

could simplify lots of policies especially where approle plugin is being used.

[chrishoffman]

@sielaq Yes, that is true but these have to be encoded into each backend and do not provide centralized management available to all backends. We have seen requests in the past to extend token metadata to additional backends but have decided not to pursue it because it has to be customized per backend. The identity system provides the same functionality but centralizes all the functionality and makes it available to all auth methods.

[sielaq]

@chrishoffman thanks for clarification.
The only problem I have (probably different from @lcgkm, but still around this issue)
is: that we use very cool project
https://github.com/nemosupremo/vault-gatekeeper
to let application accessing properties/secrets...

Using vault-gatekeeper you can match the app name (that runs in mesos) with AppRole (role_name),
and you get temporal token back for accessing own secrets. In that moment app, that want to access own-namebased-secret, require a policy per application. I cannot create a simple one policy like:

path "secrets/{{identity.entity.name}}" {
    capabilities = ["read"]
}

because identity.entity.name is not the same like role_name and I have no role_name in templating :( (or might be I have overseen something ? )

[lcgkm]

#9529