Templated ACL does not resolve group id by name

[mdegel]

Describe the bug When using ACL for resolving the id of a group by name for a path access in a policy, this seems not to work. Example policy:

path "identity/*" {
  capabilities = ["list"]
}

path "identity/entity-alias/*" {
  capabilities = ["list", "read"]
}

path "identity/group/id/{{identity.groups.names.secret_users.id}}" {
  capabilities = ["list", "read", "create", "update"]
  allowed_parameters = {
    "policies" = [["secret_rw"]]
    "*" = []
  }
}

Attempting to modify the group with this policy ends in permission denied.

To Reproduce Steps to reproduce the behavior:

1. Run a vault dev server
2. Create a new auth method (e.g. userpass) and a user testing (including identity)
3. Create two internal groups (secret_admin and secret_users)
4. Assign the user testing to the group secret_admin
5. Grant policy described above to the group secret_admin
6. Login as testing and attempt to modify (or even read) secret_users
7. See error

Replacing the template with the group id directly (by looking it up), fixes the issue (group can be modified as intended). Example:

path "identity/group/id/{{identity.groups.names.secret_users.id}}" {

-->

path "identity/group/id/b55713c6-54aa-1db1-039b-2240e36347d7" {

Expected behavior Using the ACL with the template should work.

Environment:

$ vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    1
Threshold       1
Version         1.14.0
Build Date      2023-06-19T11:40:23Z
Storage Type    inmem
Cluster Name    vault-cluster-b65c7ab8
Cluster ID      4fa74630-04c7-9f90-2805-08e6c98d11cd
HA Enabled      false

$ vault version
Vault v1.14.0 (13a649f860186dffe3f3a4459814d87191efc321), built 2023-06-19T11:40:23Z

[maxb]

This is functioning as designed, although the Vault documentation is severely lacking in a correct explanation of what the design is...

The identity.groups. lookups are not only a way to avoid writing IDs in policy text - they also cause the entire path block to conditionally only apply at run time, if the entity being checked against the policy, is a member of the relevant group.

Since your user testing is not a member of secret_users, the described policy does not apply to it.

[mdegel]

Thanks for the answer. Adding the user testing to the group secret_users indeed solves my problem.

Just to clarify: If I use a templated ACL for resolving a group, I always must be a member of any group I'm referring to? Is there any documentation, why this is implemented that way (at least to me that's not necessarily expected behavior)? Also is the approach described feasible (having an admin group, which is allowed to manage user groups), or is it maybe the wrong concept in the first place (judging from Vaults design concept)?

[maxb]

If I use a templated ACL for resolving a group, I always must be a member of any group I'm referring to?

Yes.

Is there any documentation, why this is implemented that way (at least to me that's not necessarily expected behavior)?

No - or at least, if there is, I've never found it.

Also is the approach described feasible (having an admin group, which is allowed to manage user groups)

It is doable, but as you've already discovered, becomes a bit messy, since you have to block the restricted admin group from also reconfiguring policies attached to the group.

Also, if a member of secret_admin adds someone who is supposed to have global Vault administrative powers to secret_admin, the intended global admin will now find themself blocked from modifying the policies assigned to the secret_users group, or being able to delete it!

Vault policies can combine in surprising ways. Making delegated administration work as you desire can be difficult.