概览

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

借助 Cloud IAM,您可以为特定 Google Cloud 资源授予更精细的访问权限,并阻止对其他资源的访问。借助 Cloud IAM,您可以采用最小权限安全原则,只需授予对特定资源的必要访问权限即可。

Cloud IAM 的工作原理

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

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

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

Cloud IAM 架构。

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

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

例如,在上图中,Cloud IAM 政策将由 userid@gmail.com 标识的最终用户绑定到 App Engine Admin 角色 (roles/appengine.appAdmin)。如果该政策与某项目关联,则用户 userid@gmail.com 在相关项目中具有 App Engine Admin 角色。在这种情况下,用户可以查看、创建和更新 App Engine 的所有项目级层应用配置和设置。

本页的其余部分会更详细地介绍这些概念。

在 Cloud IAM 中,您要为成员授予访问权限。成员可以是以下任一类型:

  • Google 帐号
  • 服务帐号
  • Google 群组
  • G Suite 网域
  • Cloud Identity 网域

Google 帐号

Google 帐号代表开发者、管理员或与 Google Cloud 进行交互的任何其他人员。任何与 Google 帐号关联的电子邮件地址都可以作为身份,包括 gmail.com 或其他域名。新用户可以前往 Google 帐号注册页面注册 Google 帐号。

服务帐号

服务帐号是针对应用的帐号,而非针对某个最终用户的帐号。当运行托管在 Google Cloud 上的代码时,该代码将作为您指定的帐号运行。您可以根据需要创建任意多个服务帐号,来代表应用的不同逻辑组件。如需详细了解如何在应用中使用服务帐号,请参阅身份验证使用入门

Google 群组

Google 群组是 Google 帐号和服务帐号的指定集合。 每个 Google 群组都有一个关联的唯一电子邮件地址。 您可以通过点击任意 Google 群组主页上的关于找到与 Google 群组关联的电子邮件地址。如需详细了解 Google 群组,请参阅 Google 群组首页。

Google 群组是一种将访问权限政策应用于一组用户的便捷方式。您可以同时授予和更改整个群组的访问权限控制,而不是每次授予或更改一个用户或服务帐号的访问权限控制。您还可以轻松地向 Google 群组添加成员以及从中移除成员,而不用通过更新 Cloud IAM 政策添加或移除用户。

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

G Suite 网域

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

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

Cloud Identity 网域

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

allAuthenticatedUsers

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

allUsers

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

当经过身份验证的成员尝试访问资源时,Cloud IAM 会检查该资源的 Cloud IAM 政策,以确定是否允许该操作。

本节介绍授权流程中涉及的实体和概念。

资源

如果用户需要特定 Google Cloud 资源的访问权限,您可以向该用户授予该资源的相应角色。例如,项目Compute Engine 实例Cloud Storage 存储分区都属于资源。

某些服务支持在比项目级层更细化的粒度中授予 Cloud IAM 权限。例如,对于特定 Cloud Storage 存储分区,您可以向用户授予 Storage Admin 角色 (roles/storage.admin),或者对于特定 Compute Engine 实例,您可以向用户授予 Compute Instance Admin 角色 (roles/compute.instanceAdmin)。

在其他情况下,您可以在项目级层授予 Cloud IAM 权限。然后,该项目中的所有资源都会继承该权限。 例如,要授予对项目中所有 Cloud Storage 存储分区的访问权限,请授予对项目的访问权限,而不是对每个存储分区的访问权限。或者,要授予对项目中所有 Compute Engine 实例的访问权限,请授予对项目的访问权限,而不是对每个实例的访问权限。

如需了解可对哪些资源授予哪些角色,请参阅了解角色,并参阅给定角色的最低资源要求列。

权限

权限决定了可以对资源执行的操作。在 Cloud IAM 场景中,权限以 <service>.<resource>.<verb> 的形式表示,例如 pubsub.subscriptions.consume

权限通常与 REST API 方法一一对应。也就是说,每项 Google Cloud 服务都有与该服务公开的各 REST API 方法关联的一组权限。该方法的调用方需要这些权限才能调用该方法。例如,如果您使用 Pub/Sub,并且需要调用 topics.publish() 方法,则必须拥有该主题的 pubsub.topics.publish 权限。

您不能直接向用户授予权限,而是要确定包含相应权限的角色,然后将这些角色授予用户。

角色

一个角色对应一组权限。您不能直接向用户授予权限,而是为用户授予角色。向用户授予某角色,即授予该角色包含的所有权限。

角色映射权限

Cloud IAM 中有三种角色:

  • 原初角色:Google Cloud Console 中之前提供的角色。 这些角色包括 Owner、Editor 和 Viewer。如果可能,请避免使用这些角色,因为它们包含所有 Google Cloud 服务的各种权限。

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

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

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

Cloud IAM 政策

要为用户授予角色,您可以创建 Cloud IAM 政策,这是一组定义谁拥有何种访问权限的语句集合。政策与资源关联,并在每次访问资源时实施访问权限控制。

Cloud IAM 政策。

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

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

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

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

{
      "bindings": [
        {
          "role": "roles/storage.objectAdmin",
           "members": [
             "user:alice@example.com",
             "serviceAccount:my-other-app@appspot.gserviceaccount.com",
             "group:admins@example.com",
             "domain:google.com"
           ]
        },
        {
          "role": "roles/storage.objectViewer",
          "members": [
            "user:bob@example.com"
          ]
        }
      ]
    }
    

Cloud IAM 和 Policy API

Cloud IAM 提供了一组方法,您可以使用这些方法在 Google Cloud 资源上创建和管理访问权限控制政策。这些方法由支持 Cloud IAM 的服务公开。例如,Cloud IAM 方法由 Resource Manager、Pub/Sub 和 Cloud Life Sciences API 公开(仅举几例)。

Cloud IAM 方法有:

  • setIamPolicy():设置资源政策。
  • getIamPolicy():获取之前设置的政策。
  • testIamPermissions():测试调用者是否具有资源的指定权限。

您可以在支持 Cloud IAM 的每项服务的文档中找到这些方法的 API 参考主题。

政策层次结构

Google Cloud 资源以分层方式进行组织:

  • 组织是层次结构中的根节点。
  • 文件夹是组织的子项。
  • 项目是组织或文件夹的子项。
  • 每个服务的资源都是项目的后代。

每项资源只有一个父级。如需了解详情,请参阅 Resource Manager 资源层次结构

下图为 Google Cloud 资源层次结构的一个示例。

Cloud IAM 资源的层次结构。

您可以在资源层次结构中的任一层级设置 Cloud 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 角色。

Cloud IAM 政策层次结构遵循与 Google Cloud 资源层次结构相同的路径。如果更改资源层次结构,政策层次结构也会发生更改。例如,将项目移到组织中会更新该项目的 Cloud IAM 政策,新版政策将沿用组织的 Cloud IAM 政策。

子级政策不能限制在更高层级授予的访问权限。例如,如果您为用户授予某个项目的 Editor 角色,并为同一位用户授予子资源的 Viewer 角色,那么该用户仍具有该子资源的 Editor 角色。

Cloud IAM 对 Google Cloud 服务的支持

使用 Cloud IAM 时,系统会检查所有 Google Cloud 服务中的每个 API 方法,以确保发出 API 请求的帐号具有使用相应资源的适当权限。

在 Cloud IAM 问世之前,您只能授予 Owner、Editor 或 Viewer 角色。这些角色在项目上提供了非常广泛的访问权限,并且不允许细化职责分离。现在,Google Cloud 服务提供其他预定义角色,这些角色可提供比 Owner、Editor 和 Viewer 角色更精细的访问权限控制。例如,Compute Engine 提供 Instance Admin 和 Network Admin 等角色,App Engine 提供 App Admin 和 Service Admin 等角色。除了 Owner、Editor 和 Viewer 原初角色之外,还提供这些预定义角色。

大多数 Google Cloud 服务都可以使用预定义角色。如需了解详情,请参阅所有预定义角色列表。如果您需要更丰富的控制权限,请考虑创建自定义角色

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

后续步骤