Adding individual members to each role is painful. Cloud IAM Groups are used to apply policies (who accesses what) to an entire groups of users (see this post to understand what constitutes a GCP user).

Three groups that I absolutely recommend are Network Admins, Security Admins and Project Creators.

Use Case - We want to allow PROJECT CREATION for a set of users, and only for this set of users.

Step 1 - Create a new group from our Cloud Identity admin console called Project Creator.

Step 2 - Assign this group to a Resource, in this case a FOLDER (this could have been an ORG as well - all FOLDERS under the ORG would have inherited the policy that we are about to assign)

Step 3 - Make the role assignment (PROJECT  Creator Role)

project creator GCP
project creator GCP

Use Case - Within a PROJECT, we need a set of users to have only read-only access to VMs, but we want another set of users to have full access (i.e. be able to spin up VMs)

Create two groups vm-readonly and vm-admin. We can assign these groups the relevant roles. Using predefined roles means that they are managed by Google, and any additional permissions that are added to a role would mean that your member automatically gets these.

compute viewer GCP group
compute viewer GCP group

Where did we use Policies?

You may have noticed that the post title had policies, and yet, we did not seem to use it anywhere. Actually, when we make the role assignments for a group, that itself creates an IAM policy binding between the identity and the resource.

For e.g. - we could spell out the same thing via gcloud

gcloud projects add-iam-policy-binding my-project-name –member='user:groupemail@blahblah' –role='roles/editor'

This would make the entire group of users, EDITOR on the specific project my-project-name

Need a hands-on, GCP Consultant?

Need help with your GCP journey? Start the conversation today.