Login with subset of allowed policies.

[mberhault]

Is your feature request related to a problem? Please describe.
When a user has policies in Vault corresponding to multiple roles (for example, we may have a "production admin" and a "staging admin", each granting accress to completely different sets of secrets), we would like to be able to interact with Vault using a subset of the allowed policies.
The goal is to add a safety mechanism to limit some operators errors.

Describe the solution you'd like
Specify a "profile" (or "role", etc.., the terminology is unclear) at login time.
This "profile" could be an existing group, a list of groups, or a list of policies.
All operations performed within that session would then be limited to the policies available to the specified group(s).

Describe alternatives you've considered
Short of completely separate identifies (either separate auth methods, or separate identities for a given method), there is no good way to do this that I'm aware of.

There are many alternative implementations for this. eg:

• a "profile" (or virtual identify) that can be assumed by an identify.
• a completely new type of object that would allow this

Explain any additional use-cases
Our main use case is to provide additional safeguards for operators. This could conceivably be used by automated systems as well, although these are more likely better separated at the source authentication identity.

Additional context
This type of "role selection" can be done using some auth methods. For example, the gcp auth method supports multiple roles with different policies, and "assumable" by the same requester (identified by project/service account/etc). By requesting a specific role, access to secrets can be limited to the ones needed for that role.
A more generalized approach of this type of "role selection" would be of great value.

[briankassouf]

Which auth method are you attempting to do this with? As you already mentioned gcp, and most other auth methods, have a role distinction that allow you to specify different sets of policies to apply to the token. This is already generalized across most of the backends, but curious if there is one in particular that is missing

[mberhault]

We are currently using the github auth method and will likely enable JWT soon (with OIDC from Google), using entity aliases to tie multiple login methods into a single entity. That entity would have policies granted by its group memberships while the per-auth identifiers would have no directly-attached policies.

One solution could indeed be to have all auth methods support this type of selection. However, a closer integration with the identity system would be very convenient as aliases are perfect to ignore the auth method and focus on the actual identity.

Another complex aspect of our system is that we're planning on using groups as the main aggregator of distinct policies, making per-auth identity policies tricky to juggle.

[jefferai]

An existing way to do this would be to just create a child token with a limited subset.

[mberhault]

It would, and this would work in the case where the subset of policies is known in advance. In the case of policies inherited from group memberships I would need to resolve all of these myself ahead of time, duplicating work otherwise done automatically by Vault.

[fcomte]

I have the same problem. I develop a service with distribute vault token to users.
I would like that my application generate token with a subset of policies to scope his access to a specific context.
This subset of policies could not be a known policies nor a specific role for vault. I would love that my application ask a token to vault with 2 parameters : a role and a policy in json. The effective policy could then be the intersection between the role policy and the asked policy.