Add new, optional policies_claim option to JWT roles

[mike-healey]

Overview

Add an optional "policies_claim" to JWT roles, allowing the JWT to directly specify which Vault policies should be applied to the returned token. This allows more complex RBAC configurations where a user can have multiple roles within a group all under control of an external directory - without having to duplicate the user, role and group relationships in Vault.

Design of Change

This design closely mirrors how the existing "groups_claim" works. The JWT role creator specifies the JWT claim field that will contain the list of Vault Policies to apply to the returned token.

Contributor Checklist

Doc update: hashicorp/vault#8978

I have run make test and done local testing of the new option for my own needs. I'm not aware of a larger acceptance suite for this plugin, but will happily run it if someone can point me to instructions on how to do so.

[x ] Add relevant docs to upstream Vault repository, or sufficient reasoning why docs won’t be added yet
[ ] Add output for any tests not ran in CI to the PR description (eg, acceptance tests)
[ x] Backwards compatible

[hashicorp-cla]

All committers have signed the CLA.

[mike-healey]

Can I get some feedback on this PR or some direction on what to do next? It's my first submission to Vault, so please forgive me if I missed something I'm supposed to do.

[mike-healey]

@kalafut , do you have thoughts on this?

[kalafut]

Hi @mike-healey. This is still being discussed. Directly using externally provided roles is a different RBAC model for sure, though presumably the ability to configure an IdP is also highly privileged. A feature like this would probably need some additional configuration options, like "allowed_policies", and perhaps a backend-level flag to control whether roles may even be configured this way.

[mike-healey]

Thanks for the update @kalafut. The backend-level flag makes sense to me. The "allowed_policies" could make sense in some scenarios, but breaks the model in others (such as mine). In my use case, I'm adding/removing/updating policies as organizations, groups, users, and roles are changed. So I don't know the "allowed_policies" at the time of enabling the role.

However, a "disallowed_policies" would make a lot of sense in my use case - where certain higher-privileged policies could be protected. In my case, the high-privilege policies are statically named and created when the vault is initialized - so they are knowable when the role is enabled.

So maybe both "allowed_policies" and "disallowed_policies" would be useful.

Edit: Just had a thought. If the "allowed_policies" allowed for wildcards, I could make it work, instead of having a "disallowed_policies" option.

[austingebauer]

Hi, @mike-healey. I don't think this is something we're going to accept. I recognize there are challenges in configuring Vault authorization with roles and identity (esp. your point on duplication). I'm just not certain we want to set the precedent of allowing for direct use of externally provided policy information. I'm not aware of another Vault auth method that does this today. It leaves me thinking this could be better solved by making Vault's identity system easier to onboard / get external identity into.

Additionally, I don't see sentiment that this solves an important problem for a majority of users. I don't want to add more configuration complexity for something that feels like an uncommon pattern.

I'm going to close this issue. I'm happy to hear your thoughts if it's still a problem you're looking to get solved.