Prevent IAM escalation in GCP

Question

I want to create a GCP project and to grant access on specific APIs / permissions to a team.

But I want them to be autonomous : they should be able to create their own service accounts on the scopes I allow.

The issue is that if I give them the IAM editor permisson, they can grant themselves any other permission in the project.

The Kubernetes's RBAC API is very well designed for that and a user who is able to modify the roles can't put more permission than the ones he has.

So is it possible to have for example a user with the Cloud SQL admin role, to allow him to grant similar permissions to service accounts, but also to prevent him from granting Cloud Storage permissions ?

Answer 1

I want to create a GCP project and to grant access on specific APIs / permissions to a team.

You can do that for services, that is one of the reasons that Google IAM exists. You cannot specify roles for APIs specifically - you can prevent any APIs from being enabled by not granting permission to enable services. You can use Organization Policy Contraints to prevent certain APIs from being enabled for the project but not for individuals.

But I want them to be autonomous : they should be able to create their own service accounts on the scopes I allow.

This is not supported by Google Cloud IAM. If you have permission to create a service account (roles/iam.serviceAccountAdmin), you also have permission to assign roles to that service account. This is an admin level permission that should only be granted to admins and not regular users. Manage this role carefully as an admin can create a service account with the Project Owner role.

So is it possible to have for example a user with the Cloud SQL admin role, to allow him to grant similar permissions to service accounts, but also to prevent him from granting Cloud Storage permissions ?

This is not supported. In order to have permission to assign roles to a service account, you must be a service account admin.

Answer 2

Sadly not. It's not possible to prevent "roles/permission escalation". If someone is IAM admin, he can assign the role that her want, even to himself and higher they hide current permission.

However, you have policies which allow you to limit things on the project or organisation: allowed API, external account allowed, public IP...