Templating policy parameter to allow for group aliases

[fernando-villalba]

In vault templating policies you have:

identity.entity.aliases.<<mount accessor>>.name
It would be useful to have something like this as well:

identity.group.aliases.<<mount accessor>>.name
In that way if you are a member of a external group by an oidc provider or something like that you could have a policy like this:

path "kv/+/services/{{identity.group.aliases.<<mount accessor>>.name}}/*"
{
  capabilities = ["create", "read", "update", "delete", "list"]

}

This would allow you to create groups that are automatically granted access to a folder of their group name.

If this is already possible to do in any other way, or if this is the wrong way to approach this, please do let me know

[tyrannosaurus-becks]

Hi! Thanks for opening this. That does seem like it would be useful. Have you already tried using identity.group.aliases.<<mount accessor>>.name and found that it didn't work? I wasn't clear on that from the issue.

[fernando-villalba]

@tyrannosaurus-becks Yes I tried that and it didn't work. It's also not documented in the page I linked so I am guessing it's not supported

[randombk]

Hi, is there an indication of whether this feature request is part of the team's roadmap?

I am in a similar situation where I want to have multiple groups, each in charge of their own path. For example:

Group "ex1": path "kv/ex1/*" { capabilities = ["create", "read", "update", "delete", "list"] }
Group "ex2": path "kv/ex2/*" { capabilities = ["create", "read", "update", "delete", "list"] }
Group "ex3": path "kv/ex3/*" { capabilities = ["create", "read", "update", "delete", "list"] }

There can be many dozens of groups.

Right now, the only way to accomplish this is to create a separate and dedicated policy for each path, then associating each group with its respective policy. While this can be done in an automated manner, this feels like a hacky and coarse API that's very prone to error.

Instead, it would be good to have a way to define a single policy such as

path "kv/{{any identity.groups.names}}/*" {
  capabilities = ["create", "read", "update", "delete", "list"] 
}

with the semantic that the token is given access to any folder matching the name of a group the token is a member of. Adding looping functionality could also be a more generic way to expanding the template language to support this.

[creslinux]

To put my hand in air for this one.
My users auth from a 3rd party IDP. I have no prior knowledge of external groups that may be presented to vault but need users in their shared group to be able to read k/v under a path made up of their group name.

I can try to force the user experience through my own back-end to get ahead of the problem and manually check/create policies for any groups not in the vault already - this feels hacky and will be repetitive as my backend both does not, and does not want to, hold state/persist any user data including group names in itself.

[randombk]

Hi, I'm checking back in to see if there's been any updates to this issue. Where there any new features that could simplify this scenario, or has anyone found easy workarounds?

[maxb]

I'd be pretty eager to see something like this.

There is a sort-of workaround that can be done in Vault Enterprise with Sentinel policies, but it's really uncomfortable, as you have to give really over-broad access to a collection of paths at the ACL policy layer (e.g. to kv/*), and then rely on Sentinel policy to block that access if the path doesn't match kv/{name of a group the user is in}/* - and really hope no-one ever accidentally gives the broad ACL policy without the conter-acting Sentinel policy to any token. Furthermore, if you do it that way, you then are unable to use ACL policies to grant further targeted access to specific paths, in addition to the group-named path segments. I'm not really happy with this workaround.

The biggest issue that I can see with this feature request, is that currently ACL templating expands each {{ }} placeholder to one single string, or templating expansion fails. But a user can be in multiple groups, so this feature would require that ACL templating could now take a single input path string, and expand it to multiple result strings. Not impossible at all, but a bit of a paradigm shift that would require changing various API signatures.

[ianferguson]

@maxb I drafted a (very rough) proof-of-concept for expanding identity groups in an ACL template into multiple ACLs last summer: main...DataDog:vault:ianferguson/group_expansion_in_policy_acls

I didn't have a chance to polish it up enough to open upstream, but if there is general interest and the maintainers of this project are open the contribution I could likely spend some time finishing it up in the next few weeks

[maxb]

At this point we're going to need a member of HashiCorp to pronounce whether this is a change they would be open to, or not.

[ncabatoff]

I have some minor reservations about the proposed implementation, or rather, I'm wondering if there's a smaller change that could achieve the desired effect. The current intended way to approach this is, as noted:

Right now, the only way to accomplish this is to create a separate and dedicated policy for each path, then associating each group with its respective policy.

Instead of allowing for identity templating in general to handle looping or expanding group aliases, what about solving this by allowing special templating behaviour in the case where the policy is attached to a group? If the issue is "I don't want to have to manage dozens of policies for my dozens of groups", this could I think address that?

Something like

path "kv/{{identity.thisgroup.name}}/*" {
  capabilities = ["create", "read", "update", "delete", "list"] 
}

Using identity.thisgroup in a template of a policy that isn't coming from group membership would result in that policy path being ignored when computing ACLs. It would be nicer to return an error when you try to assign such a policy to a non-group context (e.g. to an entity, or a token create), but that's not practical since policies can be changed after the fact.

I haven't looked into the feasibility of this, it's possible I'm overlooking something at the code level that would make this hard or impossible. I wanted to float the idea and get feedback on usability before I spent that time.

[maxb]

I see what you mean... but that would mean that when gathering up the set of relevant policies to merge, Vault would now have to track via which group each of them was applied. You might even get into the situtation where a user is provided with the same policy via multiple of their group memberships, but now, since the policy evaluation needs to consider the group it was linked via, the same policy might need to be evaluated multiple times, one for each group granting it - rather than simply deduplicating, as Vault can now. It might end up more complicated than the other option.

It would also mean this feature could only be used with groups which it was explicitly configured to be used with. At least for my use-case, we are looking to be able to permission a folder in a KV, in which people can create folders which will be locked to the members of the group matching the name of the folder, with as little configuration needed as possible.

[ianferguson]

@ncabatoff those reservations make sense to me and the alternative seems like a middle balance between ease of use/maintaining sensible control on how access proliferates

[martinlindner]

@ianferguson @ncabatoff Just checking if you guys are still planning to put some work into this.

I'm currently looking at a very similar use case to @randombk's, and it would be great to know if there's a chance to see a cleaner solution than creating a few hundred policies in the not-so-distant future ...

[ianferguson]

@martinlindner I’m not planning to work on this at this point

[martinlindner]

@ianferguson: Understood. Thanks, I appreciate the update, good to know that I shouldn't hold my breath.

Here's hoping that somebody else will be able to pick this up in the future. In the meantime, per-group policies it is ..