IAM so lost: A guide to identity in Google Cloud

Identity and access management (IAM) can seem like a gentle hill at first. It’s not too difficult to manage, assigning logins and passwords, and granting access control based on a person’s job in an organization. However, that gentle hill can shift as you start to configure IAM. Suddenly, it can feel like a steep mountain slope: Terminology and concepts overlap and slip beneath your feet, which is a serious problem because security boundaries in the cloud are based on understanding crucial identity concepts.

To help you regain solid footing, let’s start by demystifying two foundational IAM access control principles: the concepts of least privilege and separation of duties. While often intermingled, they are distinct. Least-privilege is the idea that you must assign only the minimum rights needed to perform a task, while separation-of-duties requires that these rights are segregated by job responsibility. 

Both are intended to reduce the impact of a negative act executed in your cloud environment. Just as when climbing Mount Everest, there are different climber classifications. A few of the climbers are guides, and even fewer are expedition leaders. While some of these functions might have overlapping responsibilities, specific jobs such as guides are focused on getting climbers to the top of the mountain. 

For example, you wouldn’t want another random climber trying to lead the operation which could potentially put individuals in danger. You want an experienced expedition leader to be in charge.

How to summit the peak of access control

Now we can start to scale the mountain of access control. To build an IAM architecture that supports these concepts of least privilege and separation of duties, you need to map identities to the people  in your organization. 

That may seem obvious, but terms such as personas, principals, groups, roles, allow and deny policies can seem overwhelming. What do all these words mean? You don’t have to feel lost anymore, because we can help demystify these terms to help you ascend from base camp.

Let’s review some terminology you’ll need to understand when configuring IAM in Google Cloud. 

Principal: Something that needs access to perform an action on a resource in Google Cloud. These objects can be end-user or service accounts, groups, a Google Workspace account, or a Cloud Identity domain that can access a resource. To remember this term, use the mnemonic,  “A principal is your pal in the cloud.”

Role: A collection of permissions that grants access to a resource.

Policy: A collection of roles attached to a resource. A policy will allow or deny a principal’s access to a resource.

Remember how we mentioned groups and personas? Fundamentally, these are the same thing. A persona is a job function. For example, you might have a persona called platform engineer or security analyst. These personas then become your groups when you map the humans in your organization to these job functions or personas. This matters because you want to assign permissions or roles to groups, but not directly to principals. 

 Managing IAM: Staying on top of the mountain

Let’s apply some of these concepts in a real-world scenario. Imagine you're a platform engineer for a startup. Initially, you manually assign permissions (roles) to each individual based on their needs. Maybe you even use basic roles, because it seems easier to give everyone “editor” rights. 

This approach works well when your team is small, but as your company expands and access control requirements increase, so does the complexity of managing all those permissions. New employees join, teams restructure, and responsibilities shift. Manually keeping up with these changes quickly turns into a nightmare, especially when you’re trying to achieve least-privilege and separation of duties.

Persona mapping can help address this scalability challenge with your IAM architecture. Instead of focusing on individual principals, you create groups based on job functions from your org chart. For example, you might have groups for developers, platform engineers, data scientists, and security engineers. Each group is then assigned the roles they need to perform their specific tasks. 

By associating roles with groups, you simplify administration and ensure consistent access for users with similar job functions. Consider the scenario where Varsha, a software engineer, needs access to deploy a web application hosted in Google Cloud. With persona mapping, the IAM workflow would look like this: 

1. Identify the persona: Varsha is classified as a software engineer for a web application deployed using Cloud Run.

2. Assign the group: Software engineers for this web application are mapped to the  "web-app-developer" group.

3. Grant appropriate roles: The “web-app-developer” group is assigned the  "Cloud Run Developer role,” providing the necessary read and write access to Cloud Run resources within Google Cloud.

This approach ensures that Varsha and other software engineers have the access they need while maintaining a manageable and scalable access control framework. Additionally, by assigning roles to groups, you create an IAM configuration that is self-documenting and easier to manage through automation.

To recap, by properly using the building blocks of IAM you will be able to:

• Streamline onboarding: New employees are simply added to the appropriate group based on their job function, automatically granting them the necessary access.

• Reduce administrative overhead: Manage permissions at the group level, saving you time and effort by creating a self-documenting IAM architecture.

• Enhance security: By using consistent access control across similar roles, you minimize the risk of over-provisioning permissions for your principals.

• Simplify auditing: Track access and identify potential issues more easily with clearly-defined group names based on job functions. 

By understanding these foundational concepts and using techniques such as persona mapping, you can turn that IAM mountain back into a hill. Your organization will be on the path to better access control in the cloud, which is identity-first, using a scalable and adaptable IAM architecture that grows with your organization. 

Read more about the building blocks of IAM in our documentation and in the manage identity and access section of the security, privacy, and compliance pillar of Google Cloud’s architecture framework. Also, remember our IAM policy intelligence tools, which can help you migrate to this modular, self-documenting approach.