攀登 IAM 高峰：Google Cloud 中的身份认证深度指南 | Google Cloud 博客_AI阅读总结 — 包阅AI

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.