Policy unions

[jdavisp3]

Feature Request:

Because of the longest-path matching for policies I find it very easy to remove privileges accidentally. Using, for example, LDAP authentication, I might have granted read/write access to secret/something/* to the members of group A.

Later on it turns out group B will need read access to secret/something/else/* at which point anyone in both groups now loses their former write access to secret/something/else/*.

It's not clear to me how to solve this problem cleanly with the current semantics. Personally I'd prefer a mode where the capabilities granted by all matching path statements are combined.

[spdqbr]

I've been running up against this issue as well. We have an LDAP backend with group -> policy mappings and when a user is a member of multiple groups, we sometimes end up accidentally removing privileges:
e.g. Admin has a policy allowing all permissions on '', but dev_leads has all permissions on /dev/, but only list permissions on /test/* , a member of both will lose permissions to everything but dev.

From a security standpoint, the "Match on most specific path" makes total sense. But it does make us update the admin policy more often than I'd like.

I don't pretend to have the best solution, but some options which might be useful:

• Allow a policy-merge strategy to be specified. Strategies could include:
  • default (as it works today)
  • union ( as mentioned by jdavisp3)
• Allow prioritizy ordered LDAP group -> policy mappings
  • The LDAP groups are each given a priority, and the highest priority ldap group to match determines the policies.
  • Ties in priority can then be merged in the usual way.

[aglover-zendesk]

+1, this issue is affecting us as well. I'd like to propose another solution - you can already specify which profile you want to use when generating tokens, like vault token create -policy=foo. Not intimately familiar with the LDAP backend of Vault, but supporting something like vault login -method=ldap -policy=foo would be good enough for me. Ideally this would also be exposed in the UI, but I'd settle for a CLI/API solution for now.

[jdavisp3]

+1, this issue is affecting us as well. I'd like to propose another solution - you can already specify which profile you want to use when generating tokens, like vault token create -policy=foo. Not intimately familiar with the LDAP backend of Vault, but supporting something like vault login -method=ldap -policy=foo would be good enough for me. Ideally this would also be exposed in the UI, but I'd settle for a CLI/API solution for now.

That makes sense to me. If you have the rights to a set of policies, I would think you'd have the rights to a subset of those policies.

[jefferai]

Policy composition goes both ways. What you are thinking of as a solution to an inconvenient aspect of Vault's behavior is someone else's escalation of privilege.

[jdavisp3]

Policy composition goes both ways. What you are thinking of as a solution to an inconvenient aspect of Vault's behavior is someone else's escalation of privilege.

Sure, and I am not suggesting you change the default behavior, that ship has sailed obviously. But I still maintain the behavior is inconvenient for the scenario I described and also a bit surprising and it would be nice to provide an alternative. That's what I meant by a "mode" in the original ticket -- a server-level setting.

[jefferai]

My comment was regarding the CLI/API proposal discussed in the comments above.

[farvour]

I completely disagree with this. I believe the ability to prioritize external groups in Vault is important so that conflicting policies are not chosen simply based on the specificity of the path defined in two different policies. I understand Vault is default deny, but when vault needs to compare two "conflicting" paths for a privilege set, there should be:

1.) A server side option to allow glob merging of all policies that match a particular.
2.) Ability to filter, reject or prioritize group processing order for LDAP/Okta/etc with policies (so there can "'only be one"). It's not uncommon for the team managing the directory to be different than the one managing vault, and it's also not uncommon for a user to be both part of a "developers" and an "operators" group in that same directory and end up with a policy "developers" get that is way less privileged.

Can we re-think this please?

[AlexeyDmitriev]

For me it seems logical that inside one policy best match is chosen(as documented), but if you have several policies, then it should be union of policies.

[royt-via]

@catsby , any updates on this issue?

[pezhovski]

It would be highly appreciated if you'd give some update on this issue, maybe link to roadmap (if you have plans on this) and/or some examples of how to manage it correctly.
This behaviour is not really convenient but use case seems really common.

[dilyevsky]

Is "feature request" categorization really applicable here? Current behavior basically makes it impossible to have write-capable policy for secret/* (admin policy) if there exists more restrictive policy for a more specific path (e.g secret/a/b with read capability). This part is also poorly documented in https://www.vaultproject.io/docs/concepts/policies (one could say not at all). IMO Vault should only match policies that are attached to a token not globally when evaluating the request.

[liliancahuzac]

Is there any update on this? We have also hit a wall where when a user has multiple groups with one of those having full permissions(ie: hcp-root policy), the merge with the other groups which have only read access on resources ends up taking precedence and preventing the creation/update/deletion of any resources.

Is there any workaround?

[luke-clifton]

For me it seems logical that inside one policy best match is chosen(as documented), but if you have several policies, then it should be union of policies.

100% agreed here.

The other point I would like to raise, that has confused a few people in my organisation: Removing a policy from an entity should not be able to increase their access. It happens just as often as the "adding a policy restricted my access further", though it does go unnoticed for longer (basically forever).

It also makes policy writing a globally coordinated effort, you have to understand what is in every other policy to know if the policy you are writing will have the intended effect.

I'd love a feature that would allow me to generate a token with a subset of my policies (to reduce blast radius in scripts), but the semantics of policies at the moment simply do not allow that.

This ability for a policy to both increase and decrease access makes them fundamentally not-composable without needing global reasoning. They are also not reusable. A particular policy needs to be written for a specific entity, taking into account all their needs. Re-using a policy (e.g. by assigning it to a group), does not work unless all the members have uniform requirements globally. If a user needs access to the union of paths provided by two policies, they need to have a third policy written for them. They can not re-use the other two safely. This is a nightmare in terms of maintainability.

Does anyone actually have a good use-case for the current behavior (across policy files, not within a single policy)? I'd love to see it. Any use case I can think of seems to go against the grain of Vault's "deny by default" strategy, where one might open up a bunch of stuff, then add policies to deny stuff, rather than adding policies to allow it.

[dusatvoj]

I'm facing this issue too. Is there a way to do a workaround when I have people in multiple groups but one group has only list permissions but other group has rwc...? 🤔

If I can't workaround it, is there a possibility to fix that? 🤔

[SharpEdgeMarshall]

Good to see no feedback from the team, probably it's part of those features that don't generate revenue.

[achetronic]

Is there any update on this? We have also hit a wall where when a user has multiple groups with one of those having full permissions(ie: hcp-root policy), the merge with the other groups which have only read access on resources ends up taking precedence and preventing the creation/update/deletion of any resources.

Is there any workaround?

The same happening here still in 2024. Any update on this?...

Cc: @ncabatoff @hellobontempo

[hellobontempo]

Hi there! Apologies for the lack of response on this issue. I'm not on the team that handles policies, but I've flagged this internally and will make sure it's passed to the relevant folks.

[mladlow]

Hey all,
Thanks for the feedback and conversation on this issue. We see this as a pretty big change to policies, and it's not one we're able to prioritize at this time. I've ensured that this enhancement request is labeled appropriately so that we can review it should we revisit this area. I'm also leaving the issue open in case others want to chime in with related use cases.

[scallister]

@mladlow this has been open for 6 years, and at least in my case 6 years ago affected an Enterprise client. I would imagine many of the users impacted by this use Vault Enterprise.

While I appreciate this issue is now decorated with the correct labels, it would be great to see this finally make it somewhere onto a definite roadmap so there is some kind of end date in sight.

[mladlow]

I can see that this is a popular request with a lot of interest - it's still a big change with security implications. We would need to deliberately research and plan out an effort like this in order for us to deliver a quality user experience, and to ensure we didn't have dangerous or surprising behavior changes for other users.

Vault Enterprise customers should be supported by account teams, and I would encourage them to work with those account teams to get bigger feature requests like this one prioritized and roadmapped.

We sometimes leave GitHub issues open to collect more feedback and prevent duplicate issues from being opened, so an open issue doesn't imply that the work will eventually be implemented, even if the issue has been open for some time.

[achetronic]

@mladlow What about something similar to the proposal done in OpenBao?

openbao/openbao#514 (comment)

I will define an RFC for this but as a brief summary, adding a variable to define the way the policies mix each other to be able to keep the previous behavior as default, and define another as the community is needing :)

CC: @sebastocorp

[achetronic]

I think something like this, but with paths instead of resources, would be awesome:

hashicorp/boundary#5028

Just throwing the idea here