Resource sets: narrowing what an admin role can reach
Bind a named list of groups, apps, or a user expression to a role so it stops granting org-wide. A role with nothing bound still grants everything, exactly as before.
A resource set, at /iam/governance/resource-sets, names an explicit list of groups or apps, or writes a CEL predicate over users, and binding it to a role narrows what that role's holder can actually manage. This is what turns a role called "Group admin" into "admin of these three groups" instead of every group your organisation has, without touching the role's own permission list.
The three kinds of resource set
| Kind | What it names | Required fields |
|---|---|---|
groups | An explicit list of group ids. | At least one resource_ids entry |
apps | An explicit list of app ids — the same operator-authored slugs App assignments uses. | At least one resource_ids entry |
users_expr | A CEL predicate evaluated against a target user's profile. | An expression that compiles |
A users_expr expression is validated at creation time against the same predicate compiler group rules use, so a broken expression is refused immediately rather than silently matching nothing later. The surface it can read is narrower than a group rule's, though:
Which permissions this can actually narrow
Binding a resource set only affects permissions on resources this feature knows how to scope: groups, app assignments, and users (matched by a users_expr set). Everything else a role might grant — billing, audit logs, PAM, SIEM, and so on — is not narrowable by a resource set today, so a role bound to a resource set still grants those unrelated permissions across the whole organisation exactly as before. Binding a set does not turn a role into a general-purpose scoped role; it only narrows the specific slice this feature covers.
Binding and unbinding
Bind a set to a role with PUT /organizations/{orgID}/governance/resource-sets/{id}/roles/{roleID} (idempotent — binding the same pair twice just confirms it), and remove it with the matching DELETE. The console's own Bind to role action on the resource sets screen calls the same endpoint. GET .../resource-sets/{id}/roles answers which roles are currently bound to one set — this is what lets the resource sets screen show and unbind roles per set.
It narrows an item, not the list it appears in
The narrowing check only applies when a permission is exercised against one named group, app or user — viewing, editing, deleting or assigning a specific one. It does not filter a collection route.
Deleting a set unwinds the narrowing
Deleting a resource set that is bound to one or more roles removes the binding along with it; every role that was scoped by it goes back to granting its permissions across the whole organisation, silently, the next time that permission is checked. There is no warning at delete time that a role depends on the set you are about to remove — check GET .../resource-sets/{id}/roles first if you need to know who that affects.
Permissions
| Action | Permission required |
|---|---|
| View resource sets or their role bindings | iam:governance.read |
| Create or delete a resource set, or bind/unbind a role | iam:governance.write |
What to do next
- Building a role that grants exactly enough — decide the permission list first; a resource set only narrows what it already grants.
- Delegated administration — read this before assuming a resource-set binding gives you the same thing a scoped delegated admin would.
- Group rules with expressions — the fuller expression surface a
users_exprresource set deliberately does not offer.