概览

本页面介绍了 Identity and Access Management (IAM) 的基本概念。

借助 IAM,您可以授予对特定 Google Cloud 资源的精细访问权限,并防止对其他资源的访问。借助 IAM,您可以采用最小权限安全原则,该原则要求任何人都不应拥有超出实际所需数量的权限。

IAM 的工作原理

借助 IAM,您可以通过定义谁(身份)对哪些资源具有哪种访问权限(角色)来管理访问权限控制。例如,Compute Engine 虚拟机实例、Google Kubernetes Engine (GKE) 集群和 Cloud Storage 存储分区都是 Google Cloud 资源。您用于整理资源的组织、文件夹和项目也是资源。

在 IAM 中,不会直接向最终用户授予资源访问权限,而是将权限分组为多个角色,然后将这些角色授予经过身份验证的成员。IAM 政策定义向哪些成员授予何种角色并强制执行,此政策附加到资源。经过身份验证的成员尝试访问资源时,IAM 会检查资源的政策以确定是否允许该操作。

下图说明了 IAM 中的权限管理。

IAM 架构。

此访问权限管理模型主要包含三个部分:

  • 成员。成员可以是 Google 帐号(针对最终用户)、服务帐号(针对应用和虚拟机)、Google 群组或可以访问资源的 Google Workspace 或 Cloud Identity 网域。成员的身份是指与用户、服务帐号或 Google 群组相关联的电子邮件地址;或与 Google Workspace 或 Cloud Identity 网域相关联的域名。
  • 角色。一个角色对应一组权限。权限决定了可以对资源执行的操作。向成员授予某角色,即授予该角色所包含的所有权限。
  • 政策。IAM 政策会将一个或多个成员绑定到一个角色。如果您要定义谁(成员)对某资源拥有何种访问权限(角色),则需要创建政策并将其附加到该资源。

例如,在上图中,IAM 政策将成员(如 userid@gmail.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 群组中添加成员以及从中移除成员,而不是更新 IAM 政策以添加或移除用户。

Google 群组没有登录凭据,并且您无法使用 Google 群组建立身份来发出访问资源的请求。

Google Workspace 网域

Google Workspace 网域代表在组织的 Google Workspace 帐号中已创建的所有 Google 帐号的虚拟组。Google Workspace 网域代表组织的互联网域名(例如 example.com),当您向 Google Workspace 网域添加用户时,系统会在此虚拟组内为该用户创建一个新的 Google 帐号(例如 username@example.com)。

与 Google 群组一样,Google Workspace 网域无法用于建立身份,但它们能够实现便捷的权限管理。

Cloud Identity 网域

Cloud Identity 网域就像 Google Workspace 网域,因为它代表了组织中所有 Google 帐号的虚拟组。但是,Cloud Identity 网域用户无权访问 Google Workspace 应用和功能。如需了解详情,请参阅 Cloud Identity 简介

allAuthenticatedUsers

allAuthenticatedUsers 是一个特殊的标识符,表示所有服务帐号和互联网上已使用 Google 帐号进行身份验证的所有用户。此标识符包括未关联到 Google Workspace 或 Cloud Identity 网域的帐号,如个人 Gmail 帐号。不包括未经身份验证的用户,例如匿名访问者。

allUsers

allUsers 是一个特殊的标识符,表示互联网上的任何用户,包括经过身份验证和未经过身份验证的用户。

当经过身份验证的成员尝试访问资源时,IAM 会检查该资源的 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 Console 中之前提供的角色。这些角色包括 Owner、Editor 和 Viewer。

  • 预定义角色:可提供比基本角色更精细的访问权限控制的角色。例如,预定义角色 Pub/Sub Publisher (roles/pubsub.publisher) 提供仅将消息发布到 Pub/Sub 主题的访问权限。

  • 自定义角色:您创建的角色,用于在预定义角色无法满足您的需求时根据组织的需要度身定制权限。

如需了解如何向用户授予角色,请参阅授予、更改和撤消访问权限。要了解可用的 IAM 预定义角色,请参阅了解角色。要了解自定义角色,请参阅了解自定义角色创建和管理自定义角色

IAM 政策

要为用户授予角色,您可以创建 IAM 政策,这是一组定义谁拥有何种访问权限的语句集合。政策附加到资源,用于在访问该资源时强制实施访问权限控制。

IAM 政策。

IAM 政策由 IAM Policy 对象表示。IAM Policy 对象包含一系列绑定。Binding 会将一系列 members 绑定到 role

  • role:您要授予成员的角色。roleroles/service.roleName 格式指定。例如,Cloud Storage 提供 roles/storage.objectAdminroles/storage.objectCreatorroles/storage.objectViewer 等角色。

  • members:一个或多个身份的列表,如本文的与身份相关的概念部分中所述。每个成员类型通过前缀进行标识,例如 Google 帐号 (user:)、服务帐号 (serviceAccount:)、Google 群组 (group:) 或者 Google Workspace 或 Cloud Identity 网域 (domain:)。在下面的示例代码段中,storage.objectAdmin 角色使用相应前缀授予给以下成员:user:ali@example.comserviceAccount:my-other-app@appspot.gserviceaccount.comgroup:admins@example.comdomain:google.comobjectViewer 角色授予给 user:maria@example.com

以下代码段展示了 IAM 政策的结构。

{
  "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 资源层次结构的一个示例。

IAM 资源的层次结构。

您可以在资源层次结构中的任一层级设置 IAM 政策:组织层级、文件夹层级、项目级层或资源层级。资源会继承其所有父级资源的政策。资源的有效政策是指为该资源设置的政策与从层次结构中更高层级继承而来的政策的集合。

这种政策沿用设置具有传递性;换句话说,资源继承项目的政策,项目会继承文件夹的政策,文件夹会继承组织的政策。因此,组织层级的政策也适用于资源层级。

例如,在上图中,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 政策。

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 服务都可以使用预定义角色。如需了解详情,请参阅所有预定义角色列表。如果您需要更好地控制权限,请考虑创建自定义角色

您可以为用户授予某些角色,从而以比项目级更精细的粒度访问资源。例如,您可以创建一个 IAM 访问权限控制政策,向某位用户授予特定 Pub/Sub 主题的 Subscriber 角色。所有预定义角色列表显示接受每个角色的最低级层或最精细的资源类型。

后续步骤