本页面介绍了 Google Cloud 的 Identity and Access Management (IAM) 系统的工作原理以及如何使用它在 Google Cloud 中管理访问权限。
借助 IAM，您可以授予对特定 Google Cloud 资源的精细访问权限，并防止对其他资源的访问。借助 IAM，您可以采用最小权限安全原则，该原则要求任何人都不应拥有超出实际所需数量的权限。
IAM 的工作原理
借助 IAM，您可以通过定义谁（身份）对哪些资源具有哪种访问权限（角色）来管理访问权限控制。例如，Compute Engine 虚拟机实例、Google Kubernetes Engine (GKE) 集群和 Cloud Storage 存储桶都是 Google Cloud 资源。您用于整理资源的组织、文件夹和项目也是资源。
在 IAM 中，不会直接向最终用户授予资源访问权限，而是将权限分组为多个角色，然后将这些角色授予经过身份验证的主账号。（过去，IAM 通常将主账号称为成员。部分 API 仍然使用此术语。）
允许政策也称为 IAM 政策，用于定义和强制执行向哪些主账号授予哪些角色。每个允许政策都会附加到资源。经过身份验证的主账号尝试访问资源时，IAM 会检查资源的允许政策以确定是否允许该操作。
下图说明了 IAM 中的权限管理。
此访问权限管理模型主要包含三个部分：
- 主账号。主账号可以是 Google 账号（针对最终用户）、服务账号（针对应用和计算工作负载）、Google 群组或 Google Workspace 账号或可以访问资源的 Cloud Identity 网域。每个主账号都有自己的标识符，标识符通常是电子邮件地址。
- 角色。一个角色对应一组权限。权限决定了可以对资源执行的操作。向主账号授予某角色，即授予该角色所包含的所有权限。
- 政策。允许政策是角色绑定的集合，这些绑定将一个或多个主账号绑定到各个角色。如果您要定义谁（主账号）对某资源拥有何种访问权限（角色），则需要创建允许政策并将其附加到该资源。
例如，在上图中，允许政策将主账号（如 user@example.com）绑定到角色，如 App Engine Admin 角色 (roles/appengine.appAdmin)。如果该允许政策关联到某个项目，则主账号会在该项目中获得指定的角色。
本页的其余部分会更详细地介绍这些概念。
与身份相关的概念
在 IAM 中，您要为主账号授予访问权限。主账号可以是下列类型之一：
- Google 账号
- 服务账号
- Google 群组
- Google Workspace 账号
- Cloud Identity 网域
- 所有经过身份验证的用户
- 所有用户
Google 账号
Google 账号代表开发者、管理员或与 Google Cloud 进行交互的任何其他人员。任何与 Google 账号关联的电子邮件地址都可以作为身份，包括 gmail.com 或其他域名。新用户可以通过转到 Google 账号注册页面来注册 Google 账号。
服务账号
服务账号是针对应用或计算工作负载（而非单个最终用户）的账号。当运行托管在 Google Cloud 上的代码时，该代码将作为您指定的账号运行。您可以根据需要创建任意多个服务账号，以表示应用的不同逻辑组件。如需详细了解如何使用服务账号对应用进行身份验证，请参阅服务账号。
Google 群组
Google 群组是 Google 账号和服务账号的指定集合。每个 Google 群组都有一个关联的唯一电子邮件地址。您可以通过点击任意 Google 群组主页上的关于来找到与 Google 群组关联的电子邮件地址。如需详细了解 Google 群组，请参阅 Google 群组首页。
Google 群组是将访问权限控制应用于一组用户的一种便捷方式。您可以一次授予和更改整个群组的访问权限控制，而不是一次授予或更改一个用户或服务账号的访问权限控制。您还可以轻松地向 Google 群组中添加主账号以及从中移除主账号，而不是更新允许政策以添加或移除用户。
Google 群组没有登录凭据，并且您无法使用 Google 群组建立身份来发出访问资源的请求。
Google Workspace 账号
Google Workspace 账号代表其包含的所有 Google 账号的虚拟组。Google Workspace 账号与贵组织的互联网域名相关联，例如 example.com。为新用户（例如 username@example.com）创建 Google 账号时，系统会将该 Google 账号添加到 Google Workspace 账号的虚拟组中。
与 Google 群组一样，Google Workspace 账号无法用于建立身份，但它们能够实现便捷的权限管理。
Cloud Identity 网域
Cloud Identity 网域就像 Google Workspace 账号，因为它代表了组织中所有 Google 账号的虚拟组。但是，Cloud Identity 网域用户无权访问 Google Workspace 应用和功能。有关详情，请参阅 Cloud Identity 简介。
所有经过身份验证的用户
值 allAuthenticatedUsers 是一个特殊的标识符，表示所有服务账号和互联网上已使用 Google 账号进行身份验证的所有用户。此标识符包括未关联到 Google Workspace 账号或 Cloud Identity 网域的账号，如个人 Gmail 账号。不包括未经身份验证的用户，例如匿名访问者。
此主账户类型不包含来自外部身份提供方 (IdP) 的身份。如果您使用员工身份联合或工作负载身份联合，请勿使用 allAuthenticatedUsers。请改为以下之一：
- 要包含来自所有 IdP 的用户，请使用
allUsers。 - 要包含来自特定外部 IdP 的用户，请使用员工身份池中的所有身份或工作负载身份池中的所有身份的标识符。
某些资源类型不支持此主账号类型。
所有用户
值 allUsers 是一个特殊的标识符，表示互联网上的任何用户，包括经过身份验证和未经过身份验证的用户。
某些资源类型不支持此主账号类型。
与访问管理相关的概念
当经过身份验证的主账号尝试访问资源时，IAM 会检查该资源的允许政策，以确定是否允许该操作。
本节介绍授权流程中涉及的实体和概念。
资源
如果用户需要对特定的 Google Cloud 资源的访问权限，您可以向该用户授予该资源的相应角色。例如，项目、Compute Engine 实例和 Cloud Storage 存储桶都属于资源。
某些服务支持以比项目级层更精细的粒度授予 IAM 权限。例如，对于特定 Cloud Storage 存储桶，您可以向用户授予 Storage Admin 角色 (roles/storage.admin)，或者对于特定 Compute Engine 实例，您可以向用户授予 Compute Instance Admin 角色 (roles/compute.instanceAdmin)。
在其他情况下，您可以授予项目级层的 IAM 权限。然后，该项目中的所有资源都会继承该权限。例如，要授予对项目中所有 Cloud Storage 存储桶的访问权限，请授予对项目的访问权限，而不是对每个存储桶的访问权限。或者，要授予对项目中所有 Compute Engine 实例的访问权限，请授予对项目的访问权限，而不是对每个实例的访问权限。
如需了解可对哪些资源授予哪些角色，请参阅了解角色并参阅给定角色的最低资源要求列。
权限
权限决定了可以对资源执行的操作。在 IAM 场景中，权限以 service.resource.verb 的形式表示，例如 pubsub.subscriptions.consume。
权限通常与 REST API 方法一一对应。也就是说，每项 Google Cloud 服务都有与其公开的每个 REST API 方法相关联的一组权限。该方法的调用者需要这些权限才能调用该方法。例如，如果您使用 Pub/Sub，并且需要调用 topics.publish() 方法，则必须拥有该主题的 pubsub.topics.publish 权限。
您不能直接向用户授予权限，而是确定包含相应权限的角色，然后将这些角色授予用户。 如需查看所有可用权限的列表以及包含这些权限的角色，请参阅权限参考文档。
角色
一个角色对应一组权限。您不能直接向用户授予权限，而是为用户授予角色。为用户授予一个角色就是授予该角色包含的所有权限。
IAM 中有多种角色：
基本角色：Google Cloud 控制台中之前提供的角色。这些角色包括 Owner、Editor 和 Viewer。
预定义角色：可提供比基本角色更精细的访问权限控制的角色。例如，预定义角色 Pub/Sub Publisher (
roles/pubsub.publisher) 提供仅将消息发布到 Pub/Sub 主题的访问权限。自定义角色：您创建的角色，用于在预定义角色无法满足您的需求时根据组织的需要度身定制权限。
如需详细了解角色，请参阅以下资源：
- 如需了解如何向用户授予角色，请参阅授予、更改和撤消访问权限。
- 如需了解可用的 IAM 预定义角色，请参阅了解角色。
- 如需了解自定义角色，请参阅了解自定义角色以及创建和管理自定义角色。
允许政策
要为用户授予角色，您可以创建允许政策，这是一组定义谁拥有何种访问权限的语句集合。允许政策与资源关联，用于在每次访问资源时强制执行访问权限控制。
允许政策包含一系列角色绑定。角色绑定会将主账号列表绑定到一个角色。
role：您要授予主账号的角色。role按roles/service.roleName格式指定。例如，Cloud Storage 提供roles/storage.objectAdmin、roles/storage.objectCreator和roles/storage.objectViewer等角色。members：一个或多个主账号的列表，如本文的与身份相关的概念部分中所述。每个主账号类型通过前缀进行标识，例如 Google 账号 (user:)、服务账号 (serviceAccount:)、Google 群组 (group:) 或者 Google Workspace 账号或 Cloud Identity 网域 (domain:)。在下面的示例代码段中，storage.objectAdmin角色使用相应前缀授予给以下主账号：user:ali@example.com、serviceAccount:my-other-app@appspot.gserviceaccount.com、group:admins@example.com和domain:google.com。objectViewer角色授予给user:maria@example.com。
以下代码段展示了访问政策的结构。
{
"bindings": [
{
"role": "roles/storage.objectAdmin",
"members": [
"user:ali@example.com",
"serviceAccount:my-other-app@appspot.gserviceaccount.com",
"group:admins@example.com",
"domain:google.com"
]
},
{
"role": "roles/storage.objectViewer",
"members": [
"user:maria@example.com"
]
}
]
}
IAM 和政策 API
IAM 提供了一组方法，您可以使用这些方法在 Google Cloud 资源上创建和管理允许政策。这些方法由支持 IAM 的服务公开。例如，IAM 方法由 Resource Manager、Pub/Sub 和 Cloud Life Sciences API 公开（仅举几例）。
IAM 方法有：
setIamPolicy()：设置资源上的允许政策。getIamPolicy()：获取之前设置的允许政策。testIamPermissions()：测试调用者是否具有资源的指定权限。
您可以在支持 IAM 的每项服务的文档中找到这些方法的 API 参考主题。
资源层次结构
Google Cloud 资源以分层方式进行组织：
- 组织是层次结构中的根节点。
- 文件夹是组织或其他文件夹的子项。
- 项目是组织或文件夹的子项。
- 每个服务的资源都是项目的后代。
每项资源有且仅有一个父项。如需了解详情，请参阅 Resource Manager 资源层次结构。
下图为 Google Cloud 资源层次结构的一个示例。
您可以在资源层次结构中的任一层级设置允许政策：组织层级、文件夹层级、项目级层或资源层级。资源会继承其所有父级资源的允许政策。资源的有效允许政策是为该资源设置的允许政策与从层次结构中更高层级继承而来的允许政策的并集。
这种政策沿用设置具有传递性；换句话说，资源继承项目的允许政策，项目会继承文件夹的允许政策，文件夹会继承组织的允许政策。因此，组织层级的允许政策也适用于资源层级。
例如，在上图中，topic_a 是位于项目 example-prod 下的 Pub/Sub 资源。如果您为 micah@example.com 授予 example-prod 的 Editor 角色，并为 song@example.com 授予 topic_a 的 Publisher 角色，则可以有效地为 micah@example.com 授予 topic_a 的 Editor 角色，并为 song@example.com 授予 Publisher 角色。
子资源的允许政策继承自其父资源的允许政策。例如，如果您为用户授予某个项目的 Editor 角色，并为同一位用户授予子资源的 Viewer 角色，那么该用户仍具有该子资源的 Editor 角色。如果更改资源层次结构，则政策继承关系也会发生变化。例如，将项目移到组织中会使得该项目继承组织的允许政策。
IAM 对 Google Cloud 服务的支持
使用 IAM 时，系统会检查所有 Google Cloud 服务中的每个 API 方法，以确保发出 API 请求的账号具有使用相应资源的适当权限。
Google Cloud 服务提供预定义角色，通过这些角色提供精细的访问权限控制。例如，Compute Engine 提供 Compute Instance Admin 和 Compute Network Admin 等角色，而 App Engine 提供 App Engine Admin 和 App Engine Service Admin 等角色。
大多数 Google Cloud 服务都可以使用预定义角色。如需了解详情，请参阅所有预定义角色列表。如果您需要更好地控制权限，请考虑创建自定义角色。
您可以为用户授予某些角色，从而以比项目级更精细的粒度访问资源。例如，您可以创建一个允许政策，向某位用户授予特定 Pub/Sub 主题的 Subscriber 角色。所有预定义角色列表显示接受每个角色的最低级层或最精细的资源类型。
IAM API 的一致性模型
IAM API 提供最终一致性。换句话说，如果您使用 IAM API 写入数据，然后立即读取该数据，则读取操作可能会返回旧版数据。此外，您进行的更改可能需要一段时间才能影响访问权限检查。
这种一致性模型会影响 IAM API 的工作方式。例如，如果您创建了一个服务账号，然后在另一个请求中立即引用该服务账号，则 IAM API 可能会提示找不到该服务账号。出现这种行为的原因是操作是最终一致的；新服务账号可能需要一段时间才能供读取请求使用。
后续步骤
- 如需查看可用 IAM 角色的列表，请参阅了解角色。
- 如需获取有关选择最合适的预定义角色的帮助，请参阅选择预定义角色。
- 要了解如何针对您的特定需求创建角色，请参阅了解自定义角色。
- 如需了解如何向主账号授予、更改和撤消 IAM 角色的说明，请参阅授予、更改和撤消源的访问权限。
- 探索 Policy Intelligence 工具，这些工具有助于您了解和管理允许政策，以便主动改进您的安全配置。
- 要了解如何保护应用，请参阅 Identity-Aware Proxy 概览。