Google Cloud IAM 怎么理解，用户、角色和权限之间到底是什么关系

Google Cloud IAM 是 Google Cloud 中负责访问控制的核心机制。很多人在第一次接触 IAM 时，容易把“用户”“角色”和“权限”理解成三个可以直接互换的概念。实际上，它们处于不同层次：权限描述“能够做什么”，角色把一组权限组合起来，而主体则通过角色绑定获得相应的访问能力。

真正理解 IAM，关键不是记住大量角色名称，而是弄清楚“谁，在什么资源上，通过什么角色，可以执行哪些操作”。

权限决定“能做什么”

在 Google Cloud 中，Permission 是访问控制最基础的组成部分。一个权限通常对应某项具体操作，例如读取某个计算资源、创建虚拟机或者修改某项配置。

例如，某个计算资源可能涉及类似 compute.instances.get 这样的权限。它表达的是“允许读取虚拟机实例信息”，而不是“允许管理所有虚拟机”。

权限通常不会直接分配给普通用户。Google Cloud 更常见的做法是把多个相关权限组合到 Role 中，再通过 IAM Policy 将角色授予相应主体。

因此，可以把权限理解成一把把单独的钥匙，而角色则是把这些钥匙按照工作需要组合起来的钥匙串。

角色负责把权限组合起来

Role 是 IAM 中非常重要的一层。一个角色包含一组权限，可以对应某种典型的工作职责。

Google Cloud 提供大量预定义角色。例如，某些 Viewer 类角色主要用于查看资源，而某些管理员角色则包含创建、修改和删除资源所需要的更多权限。

这种设计的好处是管理员不需要逐个为员工添加权限。例如，一个开发人员需要访问某个项目中的多项资源，如果这些权限已经包含在合适的预定义角色中，管理员只需要授予这个角色即可。

不过，角色名称并不能完全代表实际权限。即使两个角色都带有“Admin”或者“Viewer”这样的名称，它们所包含的具体权限也可能完全不同。因此，在正式配置生产环境时，应该查看角色实际包含的权限，而不能只根据名称判断权限范围。

Google Cloud 还支持自定义角色。当预定义角色包含的权限过多，而企业又需要更加精确的控制时，可以根据实际需求创建 Custom Role。不过，自定义角色也意味着企业需要自行维护权限集合，管理复杂度会随之增加。

用户并不等于唯一的授权主体

另一个容易产生误解的地方，是把 IAM 中的“用户”理解成唯一的访问主体。

实际上，Google Cloud IAM 中的 Principal 可以包括个人用户、Google 群组、服务账号以及其他受支持的身份主体。企业环境通常不应该把大量权限直接分散绑定到个人账号，而应该更多利用群组和服务账号进行统一管理。

例如，一个开发团队可以建立一个 Google Group，然后把适当的 IAM 角色授予这个群组。员工加入团队时获得相应权限，离开团队后从群组中移除即可。这样比逐个修改几十甚至几百个用户的权限更加容易维护。

服务账号则主要用于应用程序、自动化任务和云服务之间的身份认证。例如，一个自动部署系统需要创建计算资源，就可以使用具有相应权限的服务账号，而不应该直接使用某名员工的个人账号运行自动化程序。

真正的关系是“主体＋角色绑定＋资源”

理解 IAM 最简单的方法，是把它看成三个核心对象之间的关系。

主体回答“谁”。

角色回答“可以做什么”。

资源层级回答“在哪里可以做”。

例如，一个开发人员可能被授予某个项目中的计算资源查看角色。这里的关系不是“用户直接拥有某个权限”，而是该用户在指定资源范围内获得了某个角色，而角色中包含相应权限。

IAM Policy 中的 Binding 就承担了连接主体和角色的作用。管理员实际上是在指定某个主体或群组，可以在某个资源范围内使用某个角色。

因此，一个完整的授权判断不能只问“这个人是什么角色”，还必须进一步确认“这个角色被授予在哪个资源层级”。

资源层级决定权限作用范围

Google Cloud 的资源具有层级结构，常见的管理层级包括 Organization、Folder、Project，以及具体资源。

IAM 策略可以在不同层级设置。上层资源授予的权限通常可以向下继承到子资源，这也是 Google Cloud 能够进行大规模统一权限管理的重要原因。

例如，企业可以在 Organization 或 Folder 层面对某个群组授予基础访问权限。下面的项目和资源通常可以继承这一授权。

这种机制非常适合大型企业，但也容易造成权限范围被无意扩大。

如果管理员在 Organization 层面授予一个范围过大的角色，那么下面大量项目都可能受到影响。一个原本只需要访问单个项目的员工，可能因此获得远超实际工作需要的访问能力。

所以，大型企业设计 IAM 时，需要同时考虑权限本身和权限所处的资源层级。

权限继承并不意味着子资源可以随意覆盖父级权限

原文中一个比较容易造成误解的说法，是把 IAM 权限继承简单理解成“子项目可以覆盖父项目权限”。

Google Cloud IAM 的实际权限评估更加复杂。不同层级的 IAM Policy 会共同参与访问判断，而获得的有效权限通常是多个层级授权结果的综合。

因此，不能简单认为在子资源上设置一个较低权限的角色，就能够自动抵消父资源已经授予的较高权限。

如果企业确实需要限制某些操作，还需要结合 IAM Deny Policies、条件等机制进行更加精细的控制。

这也是为什么大型企业不能只依赖“Folder 分层”来解决所有权限问题。资源层级解决的是组织问题，IAM 解决的是访问控制问题，两者需要结合设计。

IAM Conditions 可以进一步限制授权

对于一些需要精细控制的场景，可以使用 IAM Conditions。

条件可以根据具体情况限制某个角色的生效范围。例如，企业可能希望某个权限只针对特定资源，或者只允许访问符合某些条件的资源。

这样就可以避免为了满足一个特殊需求，而直接授予一个范围过大的角色。

不过，条件策略也会增加权限体系的复杂度。企业应该尽量保持规则清晰，并建立权限审计机制，否则当 IAM Policy 数量越来越多时，管理员自己也可能难以判断某个用户最终到底拥有多少权限。

为什么企业更应该使用群组，而不是逐个给员工授权

对于小型项目，直接给个人账号绑定角色并不困难。但当企业拥有数百甚至数千名员工时，这种方法很快就会变得难以维护。

更加合理的方式通常是按照岗位和职责建立群组。

例如，可以建立开发人员、运维人员、数据分析人员和安全团队等群组，然后分别配置适合这些岗位的角色。员工发生岗位变化时，只需要调整其群组成员身份。

这种方法不仅降低管理成本，也更容易进行权限审计。

同时，生产环境和开发环境应该尽可能分开管理。开发人员不应该因为拥有开发环境权限，就自然获得生产环境的管理权限。

服务账号则应该拥有独立的权限范围，并避免多个应用程序长期共享一个权限过大的服务账号。

最小权限原则才是 IAM 设计的核心

IAM 的最终目标并不是让管理员尽可能方便地授予权限，而是在保证业务正常运行的情况下，将权限控制在必要范围之内。

如果一个开发人员只需要查看日志，就没有必要授予项目级管理员角色。如果一个应用程序只需要读取 Cloud Storage 中的特定数据，就没有必要给予整个项目的管理权限。

权限越大，潜在风险也越大。

因此，企业应该定期检查 IAM Policy、群组成员、服务账号以及角色绑定，删除已经不再使用的账号和权限，并特别关注高权限角色。

同时，可以利用 Cloud Audit Logs 等审计能力追踪关键操作，发现异常访问后及时处理。

理解 IAM 最重要的是建立正确的思维方式：用户或者其他主体代表“谁”，角色代表“允许做什么”，资源层级决定“权限作用在哪里”，而 IAM Policy 则把这些因素组合成最终的访问控制规则。

对于小型项目，直接使用 Google Cloud 的预定义角色已经可以满足大多数需求；对于大型企业，则应该进一步结合 Organization、Folder、Project、Google Groups、Service Accounts、IAM Conditions 和最小权限原则，建立清晰的权限体系。

这样设计出来的 IAM 才不会随着企业规模扩大而迅速失控，也能够在保证员工和应用正常工作的同时，把不必要的访问权限控制在最低水平。