概览

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

Google Cloud Platform (GCP) 提供了 Cloud IAM,后者可让您通过定义谁(身份)对哪些资源具有哪种访问权限(角色)来管理访问权限控制。

IAM

借助 Cloud IAM,您可以授予对特定 GCP 资源的精细访问权限,并防止对其他资源进行不必要的访问。Cloud IAM 允许您采用最小权限安全原则,因此您只需授予对您的资源的必要访问权限即可。

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

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

Google 帐号

Google 帐号代表开发者、管理员或与 GCP 互动的任何其他人员。任何与 Google 帐号关联的电子邮件地址都可以作为身份,包括 gmail.com 或其他网域。新用户可以通过转到 Google 帐号注册页面来注册 Google 帐号。

服务帐号

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

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 政策,以确定是否允许该操作。

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

资源

您可以授予用户对 GCP 资源的访问权限。例如,项目Compute Engine 实例Cloud Storage 存储分区都属于资源。

某些服务(如 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 方法一对一对应。也就是说,每项 GCP 服务都有与其公开的每个 REST 方法相关联的一组权限。该方法的调用者需要这些权限才能调用该方法。例如,Publisher.Publish() 的调用者需要 pubsub.topics.publish 权限。

您不能直接向用户分配权限。不过,您可以为他们分配一个包含一项或多项权限的角色

角色

角色是一组权限的集合。您不能直接为用户分配权限;而应为用户授予角色。为用户授予一个角色就是授予该角色包含的所有权限。

拥有角色映射权限

Cloud IAM 中有三种角色:

  • 初始角色:Google Cloud Platform Console 中之前具有的角色将继续有效。它们是所有者编辑者查看者角色。

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

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

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

IAM 政策

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

IAM 政策

Cloud IAM 政策以 IAM Policy 对象的形式来表示。IAM Policy 对象包含一系列绑定。Binding 会将 members 列表绑定到 role

role 是您要分配给成员的角色。roleroles/<name of the role> 的形式指定。例如,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 提供了一组方法,您可以使用这些方法在 GCP 资源上创建和管理访问权限控制政策。这些方法由支持 Cloud IAM 的服务公开。例如,Cloud IAM 方法由 Resource Manager、Cloud Pub/Sub 和 Cloud Genomics API 公开(仅举几例)。

Cloud IAM 方法有:

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

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

政策层次结构

GCP 资源以分层方式组织,其中组织节点是层次结构中的根节点,项目是组织的子项,其他资源是项目的后代。每项资源有且仅有一个父项。有关详情,请参阅 Resource Manager 资源层次结构主题。

下图提供了 GCP 资源层次结构的一个示例:

资源层次结构

您可以在资源层次结构中的任一层级设置 Cloud IAM 政策:组织层级、文件夹层级、项目级层或资源层级。资源会沿用父级资源的政策。如果您在组织层级设置政策,则其所有子项目都会自动沿用该政策,并且如果您在项目级层设置政策,则其所有子项资源都会沿用该政策。资源的有效政策是指为该资源设置的政策与从层次结构中更高层级沿用而来的政策的集合。

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

例如,在上图中,topic_a 是位于项目 example-prod 下的 Cloud Pub/Sub 资源。如果您为 micah@gmail.com 授予 example-prod 的编辑者角色,并为 song@gmail.com 授予 topic_a 的发布者角色,则可以有效地为 micah@gmail.com 授予 topic_a 的编辑者角色,并为 song@gmail.com 授予发布者角色。

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

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

Cloud IAM 对 GCP 服务的支持

有了 Cloud IAM,所有 GCP 服务中的每种 API 方法都会接受检查,以确保发出 API 请求的帐号具有使用相应资源的适当权限。

在 Cloud IAM 问世之前,您只能授予所有者、编辑者或查看者角色。这些角色在项目上提供了非常广泛的访问权限,并且不允许细化职责分离。现在,GCP 服务提供额外的预定义角色,这些角色可提供比所有者、编辑者和查看者角色更精细的访问权限控制。例如,Compute Engine 提供了“实例管理员”和“网络管理员”等角色,App Engine 提供了“应用管理员”和“服务管理员”等角色。除了传统的 Owner、Editor 和 Viewer 角色之外,还提供这些预定义角色。

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

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

后续步骤

此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Cloud IAM 文档