Summary: We'd like to have other operations than .hasOnly() for setting limits on granting roles through Conditional IAM.

Our use case:

Within our GCP setup, we don't allow any user to directly manipulate GCP resources directly; all changes happen through our provisioning tooling. But inevitably, sometimes our operations people need to debug/fix things. As such, all our user accounts within GCP have read permissions by default, but two groups of administrators have projectIamAdmin permissions so they can "break the glass" through the IAM console in order to grant themselves (and others) additional permissions. In order to comply with audits and common least-privilege sense, we'd like to limit the permissions these administrators can set for themselves (and ideally also restrict who they assign these permissions to, but that might be out of scope for this request). E.g, we'd like it to be impossible to set Owner, BigQuery.Admin and other high privileged roles, forcing the users to set a more appropriate (temporary) role for themselves.

The issue:

With the current feature set outlined in 1, used in the example we followed at 2, we can only define which roles an admin can set (.hasOnly()), not which roles they cannot set (e.g. .doesNotInclude()). This would require us to maintain a list of roles admins could set, which furthermore is limited to 10 roles due to the current limitations on .hasOnly(). With an ever growing list of GCP services we offer to our teams, 10 roles is insufficient, and the mechanism as a whole would be harder to maintain than having exclusion rules.

Primary feature request:

To counter the above issue, we'd like to have the possibility to have exclusion rules in Conditional IAM rules for granting roles; the counterpart to .hasOnly(), something like .doesNotInclude() to allow for easily maintainable restrictions on role granting.

Additional feature request:

I realise this request might not be the place to address these wishes, but perhaps they give a better overview of our desired state: Currently, it's only possible to check iam.googleapis.com/modifiedGrantsByRole. As such, we can only verify and act on the roles being set. This excludes doing checks on the actors (person doing the granting, person receiving the grants). Being able to check these would allow for mechanisms like:

Preventing users to grant roles to anyone other than themselves or direct team members (through group membership)
Only allowing members of a specific group to grant BigQuery.Admin and other high privilege roles (can be solved by having a multitude of groups that have projectIAMAdmin with restrictive Conditional IAM rules, but since we have different teams administering different GCP components, this setup will become hard to maintain rather quickly, and with scattered policies also hard to audit / put into an access matrix)

Google support reference: case 28621473

If no plans exist to support scenarios as outlined above, we'd also be happy with best practices to make our wishes possible with the existing set of rules.

Issue 195441719

Links (3)

Issue metadata