<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">

We're blowing the whistle on Legacy PAM 🏀 Join us for an Access Madness Webinar on March 28

Search
Close icon
Search bar icon

Understanding GCP IAM Roles

StrongDM manages and audits access to infrastructure.
  • Role-based, attribute-based, & just-in-time access to infrastructure
  • Connect any person or service to any infrastructure, anywhere
  • Logging like you've never seen

Summary: In this article, we will provide an in-depth overview of Google Cloud Platform (GCP) identity and access management (IAM) roles. You’ll learn about how GCP IAM works and the different types of roles that can be delegated to users as well as when those roles are most appropriate in the GCP environment. By the end of this article, you’ll have a clear understanding of the pros and cons of each different role type as well as their limitations and have a GCP IAM Roles cheat sheet that administrators can turn to when looking to build a highly productive and secure access management infrastructure for teams of any size.

How GCP IAM Works

IAM is a framework of policies and technologies to ensure that the right users have the appropriate access to technology resources. GCP IAM uses the principle of least privilege to grant an account access to the minimal set of permissions required to complete a given task—ensuring users only have access to the resources they really need.

The goal of an IAM policy is to grant access for a resource to a specific authenticated identity or principal. This can come in the form of individual users or applications that need a resource to perform a task. When an authenticated identity attempts to access a resource, IAM references the attached resource policy to determine whether permission should be granted. IAM policies keep valuable digital resources safe and secure so that only specific users can access tools that control cloud functions. 

Key terms

Defining key terms will be helpful when proceeding through IAM in greater detail in terms of roles and role assignments. 

  • Principal: Google account end user or service account application or identity that needs permission to access a Google Cloud resource. 
  • Role: A collection of permissions that determine which operations can be used on a specific resource. 
  • Policy: Role constraints that bind a principal or identity to a specific action for a resource. Policies define which identities have what kind of access to an attached, specified resource. 

GCP IAM roles explained

Since permissions cannot be applied directly to users, cloud network administrators must confer roles with specific policy-based permissions to each user, group, or application. GCP roles include

  • Basic: IAM basic roles are the most limited form of GCP roles and include owners, editors, and viewers.
  • Predefined: Predefined roles provide finer-grain access to specific services in the Google Cloud. 
  • Custom: Custom roles provide finer-grain access to an organization-specific list of permissions to meet specific needs.  

When you grant a role to one principal, you grant them all of the permissions that a role contains. GCP IAM is scalable in that multiple users in one group can all take on the permissions granted from a single role. 

Basic (primitive) roles

Originally known as “primitive roles”, basic roles are defined as either owner, editor, or viewer. The levels within basic roles are concentric: owner roles include the permissions of editor roles, and editor roles include the permissions of viewer roles. Viewers only have permissions for read-only access and cannot modify existing resources and data; editors can both view resources as well as take actions to modify existing resources as well as create and delete resources. Owners can manage viewers and editors, permissions and resources for projects, and set up billing processes. 

Limitations

Basic roles predate GCP IAM and do not follow the principle of least privilege. As such, these roles are subject to increased security risks because they include thousands of permissions across all Google Cloud services. For example, granting a user the basic editor role gives them the permission to create and delete resources for most Google Cloud services across the entire project or organization. As such, basic roles should only be granted as a last resort.

Additionally, owners have stipulations depending on the infrastructural level the user is operating at. For example, owners at the project level do not have the same permissions as owners at the organization level. Furthermore, owners at the organization level cannot modify the metadata (role ID and permissions) within a role.

Basic Roles Pros and Cons

Pros

  • Easiest role to set up because it grants access to all datasets.
  • Owners can set up billing for projects. 
  • Cloud Console can grant ownership on projects to a user that is not part of the organization. 

Cons

  • Subject to high security risks. 
  • An owner at the organization-level cannot update role metadata. 
  • Basic roles do not contain permissions to perform actions across all services. 

Predefined Roles

Predefined roles give users granular access to specific resources while enhancing security by maintaining the principle of least privilege, where users are only granted the resources necessary to complete their tasks. In contrast to basic roles, predefined roles are role-binding: lower-level resources inherit the policies and role bindings of higher-level resources. This core concentricity presents a secure approach to organization-owned resources in the cloud, where only authorized users are granted access to mission-critical datasets and information. 

Predefined roles are both created and maintained by Google, which means you get the benefits of automatic updates when new permissions, features, or services are added to the Google Cloud. GCP IAM provides many different types of predefined roles for services, including Access Approval roles, Access Context Manager roles, Actions roles, and many others. 

Before delegating roles, administrators should identify which permissions need to be granted, find and select the roles that contain those permissions, and decide on which users or applications to grant those roles. 

Limitations

Delegating predefined roles can be challenging due to the sheer volume of roles available and the possibility of a user being assigned hundreds of roles. Additionally, if predefined roles are not defined specifically enough, they may end up violating the principle of least privilege by including unnecessary permissions—thereby eliminating the major security advantage of predefined roles. To get around this, teams can turn to an access tool that implements role-based access control (RBAC) to manage appropriate access to each team for the ideal GCP IAM roles hierarchy. 

In addition, while the principle of least privilege is important for security, determining the most appropriate role for a user can be tricky when there are multiple users and multiple predefined roles that need to be assigned correctly. 

Predefined Roles Pros and Cons

Pros

  • Principle of least privilege: resources are secure from unauthorized users. 
  • Provides users with granular access to specific GCP services. 
  • Automatically updated by Google with new permissions, features, and services.

Cons

  • Difficult to delegate permissions with a large volume of roles. 
  • Complex roles that include unrelated and unnecessary permissions. 
  • Custom roles need to be made when there is no predefined role for a task. 

Custom Roles

Sometimes users need to be granted more complex permissions that might not have a predefined role already in place—particularly useful when predefined roles are granting overly permissive permissions for your users’ needs. In these cases, role administrators can turn to custom roles to bundle multiple supported permissions to meet a specific need. 

A custom role must be created and granted within a specific organization or project. In support of the principle of least privilege, a custom role will only have permissions that are granted at the level at which it was created. For example, a custom role created at the project level will not have the same permissions that are only available at the organizational level, and vice versa.

Limitations

As custom roles are created and maintained by users, they do not offer the same automatically updating features as Google-maintained predefined roles. Additionally, custom roles cannot be applied to resources in other projects and organizations—they must be granted within the project or organization it was created in. This can create barriers for administrators when they have users who are working between projects. For example, when permissions that are only supported for organization-level custom roles are copied into a project-level custom role, they will display either a warning or error (e.g., not applicable for project-level custom roles, INVALID_ARGUMENT, or an HTTP 400 error code).

Custom Roles Pros and Cons

Pros

  • Present a solution to organization-specific role needs.
  • Maintains security with the principle of least privilege.

Cons

  • Can be complicated to set up and result in errors.
  • Limited to resources within the project or organization the role was created in. 
  • Does not automatically update.

Using the right GCP IAM roles to keep your infrastructure secure

Basic, predefined, and custom GCP IAM roles can help organizations delegate permissions and secure their data. Basic roles are fast and easy to set up, but offer less security than other role types. Predefined roles are built on the principle of least privilege, and therefore offer more security than basic roles. Custom roles further fine-tune the permissions granted with predefined roles, while maintaining the security of a role-type built on the principle of least privilege. 

Conclusion 

Delegating GCP IAM roles across an organization provides network administrators and organizers with a framework for creating an efficient and secure developer infrastructure. Breaking roles out into basic vs. predefined vs. custom and defining the limitations of each can be a powerful way of setting up a secure hierarchy across projects and organizations. 

Ready to unify control for all elements in your GCP infrastructure? Schedule a demo today!


About the Author

, Customer Engineering Expert, has worked in the information security industry for 20 years on tasks ranging from firewall administration to network security monitoring. His obsession with getting people access to answers led him to publish Practical Vulnerability Management with No Starch Press in 2020. He holds a B.A. in Philosophy from Clark University, an M.A. in Philosophy from the University of Connecticut, and an M.S. in Information Management from the University of Washington. To contact Andy, visit him on LinkedIn.

StrongDM logo
💙 this post?
Then get all that StrongDM goodness, right in your inbox.

You May Also Like

Identity and Access Management Implementation: 8-Step Plan
Identity and Access Management Implementation: 8-Step Plan
Identity and access management (IAM) is a collection of technologies, policies, and procedures designed to guarantee that only authorized individuals or machines can access the appropriate assets at the appropriate times. While it is an effective approach to enterprise security, IAM implementations are complex undertakings. If not done correctly, it can create security gaps that leave your organization at increased risk of a breach. Taking a measured approach will ensure your deployment is seamless and successful.
5 Reasons to Level Up From Identity to Dynamic Access Management
5 Reasons to Level Up From Identity to Dynamic Access Management
Historically, finding an infrastructure access management solution that is secure while still being easy to use has been extremely difficult. Too often, ease of use and complexity end up at odds. StrongDM addresses this challenge–and does so by integrating with your existing identity-based security initiatives. This blog details how StrongDM enables organizations to level up their access management approach to meet the requirements of Dynamic Access Management (DAM), bolster security, and streamline operations.
Map of the Secure Access Maturity Model
Evolving From Identity-Based Access to Dynamic Access Management (DAM)
This article is your map for taking the work you’ve done with identity and your identity provider (IdP) and using it as your launchpad for access management. Shifting from identity-based access to a more dynamic access approach is necessary for organizations looking to modernize their access management and better protect sensitive resources at scale and in the cloud.
AWS IAM Best Practices for Enhanced Security
12 AWS IAM Best Practices for Enhanced Security
When it comes to cloud security, AWS follows the Shared Responsibility Model. They secure the underlying infrastructure while you protect your data, applications, and systems—including the identities that access them. Integrating AWS with a dynamic access management tool like StrongDM is key to securing identities in the cloud. StrongDM centralizes access control, while AWS offers robust security measures, contributing to a solid defense against unauthorized access.
What Is SCIM Provisioning? How It Works, Benefits, and More
What Is SCIM Provisioning? How It Works, Benefits, and More
In this article, we will define SCIM and cover the basics of SCIM security. You’ll learn what SCIM stands for, how SCIM provisioning works, and why SCIM SSO is essential. By the end of this article, you will have a clear understanding of what SCIM means and how auto-provisioning via SCIM streamlines cloud identity management, increases employee productivity, and reduces IT costs.