GCP IAM roles explained
When to use basic vs predefined vs custom roles
Introduction
This is a topic that comes up at every single customer project I work on: what are IAM Roles in GCP and how should we go about them? In my work as part of Google Cloud Professional Services, I had to write a few documents explaining in detail the advantages and disadvantages of each type for various use cases and make recommendations for each customer specific use case.
This led me to create this post, to make it easy for anyone to make a decision on their IAM role strategy in GCP. First, I will offer some more context about how IAM works in GCP, which might be useful if you are used to other cloud providers, or new to GCP. Then I will describe each IAM role type to finally help you make a decision for your own organization in the end.
Spoiler alert, as a general rule, we recommend using predefined roles to limit complexity. In some cases, it can make sense for customers to manage custom roles themselves, but this decision should be carefully considered, given the additional overhead associated with it.
IAM Bindings
In Cloud IAM, identities (i.e users, groups and service accounts) can get access to resource APIs via IAM policies. In these policies, you can define one or more bindings in which members are granted an IAM role. This associates the binding’s members with all the permissions granted to this role at that policy level (organization, folder or project) and below (if any).
It is important to understand that roles can only be granted at certain levels. For instance, the Folder Viewer role would make no sense at a project level, since the resources accessed by its permissions do not live at the project level. You typically will grant IAM roles at the project or resource level (e.g a Cloud Storage bucket), but you can also do it at the Folder, or Organization level too.
Roles are composed of “permissions”. These permissions can generally be thought of as an access control for a specific Google Cloud API call. For example, the storage.buckets.list permission only allows access to the API call for listing storage buckets.
Finally, it is essential to be mindful of IAM limits and quotas which might impact your deployment strategy (e.g max number of members or groups in a binding).
Basic roles
Basic roles (formerly named primitive roles) are legacy roles that predated the existence of Cloud IAM. They are the most powerful roles available in a project, with thousands of permissions, and are managed by Google on your behalf.
This means that the permissions they encompass will automatically be updated for you, as new products or features are released.
As a general rule, only use the basic roles for testing things out, in a sandbox environment — not in production environments that contain any real data. This will limit your risks of unauthorized access to sensitive data by legitimate users or external actors in case of compromised credentials.
Predefined roles
Predefined roles are a set of IAM roles maintained by Google on customer’s behalf for each GCP service. This means that the product teams reviewed all the permissions available for a given product (or set of products) and defined the minimum set of permissions typically required for most job functions. For example, BigQuery roles (admin, dataOwner, jobUser etc.) have been created to ensure different job functions could operate without getting excessive permissions , following the separation of duty and least privilege practices.
The idea behind creating these roles is to alleviate the burden of selecting the appropriate permissions (among thousands) to use GCP services from customers, and offer an opinionated set of permissions for end users to choose from. These predefined roles are also managed by Google, which means that whenever new permissions are available in GCP (say for a new feature or product), these permissions will automatically be added to the corresponding predefined roles by Google.
A few words of caution
There are special predefined roles that allow you to set IAM permissions at various levels (organizationAdmin, folderIAMAdmin, projectIAM Admin). When granting these roles, be aware that you are granting the ability to assign ANY role to any users to someone, including basic roles.
Finally, some roles contain permissions that allow you to impersonate a service account. As a reminder, a service account is an identity that should be used by non-human entities — like robot accounts, but in some cases, it is useful to impersonate a service account to troubleshoot something for example.
Because of this, you need to be careful about assigning roles that contain the “iam.serviceAccounts.actAs” permission since it allows a user to attach a service account to a VM. This could allow them to elevate privilege by simply SSHing into that machine and using the attached service account. Also be careful of roles that let you get short or long lived credentials for service accounts, such as roles that contain the “iam.serviceAccounts.signJWT” permission which is part of the roles/iam.serviceAccountTokenCreator role(check the permission reference page to learn more). Granting these permissions grant all the service account’s permissions to your end user, as well as the ability to make API calls on its behalf, which makes it harder to enforce the non-repudiation security principle in your organization.
Limits
Some preview products might not have predefined roles yet (this is quite rare), in which case the only two options available are using primitive roles (not recommended, unless necessary) or custom roles (if possible).
Custom roles
Custom roles are similar to predefined roles, but they are created and managed by users directly. Typically you can create custom roles at the organization or a project level, by selecting the list of permissions it should have.
Limits
There are known limitations that come with custom roles. The most important one is that not all permissions are supported at any given time — meaning that in some cases, custom roles are not usable for your job function.
Other limitations to consider for custom roles:
- Limits & quotas: There is a maximum number of customer roles you can create in your organization and in each project (300 per node). Other limitations exist for custom roles (like name or description size etc.), but are less impactful, generally.
- Custom roles cannot be created at a Folder level (only Organization or project level).
- Some permissions — usually under development (alpha/preview) — might not show up in the UI, which might cause behavior changes between custom roles and the predefined ones they were created from.
Summary
It is recommended to monitor which permissions are actually used by your identities (both users and service accounts) and remove permissions that are never used over a reasonable period of time (for instance 90–120 days) unless your use case calls for it (e.g infrequent access to your resources). See IAM recommender to make this simple in GCP.
Summary
Basic roles
Pros:
- Easy to use when trying to learn GCP
- Can be useful to quickly troubleshoot something in a low-level environment
- Managed by Google (auto-updated permissions)
Cons:
- Managed by Google (auto-updated permissions)
- Too powerful: very difficult to ensure segregation of duty if using these.
- Big blast radius if an attacker gets access to an identity with these roles.
Predefined Roles
Pros:
- Less operational overhead — especially at scale
- Managed by Google (auto-updated permissions)
- More targeted than basic roles: safer to assign to users
Cons:
- Managed by Google (auto-updated permissions)
- Typically leads to more permissions than needed. This can be resolved over time using IAM recommender, or by switching to custom roles for specific use cases only.
Custom roles
Pros:
- Usually more targeted roles (smaller set of permissions overall), which facilitates the enforcement of the separation of duties security principle.
Cons:
- More operational overhead — especially at scale
- Some permissions cannot be used in custom roles
- Some predefined roles cannot be replicated entirely (see invisible permissions above)
- Cannot be created at the Folder level
- Limits on number of custom roles allowed at the org level (300) and in each project (300)
