面向 AWS 专业人员的 Google Cloud 简介:管理

更新时间:2017 年 3 月 17 日

比较 Amazon 和 Google 在各自的云环境中提供的管理服务。如果您已熟悉 Amazon Web Services (AWS) 上的身份和访问权限管理 (IAM) 机制,本文将更进一步,帮助您全方位地了解 Google 的 Identity and Access Management (IAM)。Google Cloud 和 AWS 提供类似的 IAM 解决方案。您可以使用这些工具来创建并管理云资源的权限,包括数据和应用的权限。

AWS 和 Google Cloud 均允许您向用户、群组和应用授予权限。这些权限可让获得授权的实体拥有明确定义的云资源访问权限。

下表对 AWS 和 Google Cloud 中的术语和概念进行了比对。

概念 AWS Google Cloud
编程身份 IAM 角色和实例配置文件 IAM 服务帐号
用户身份 在 IAM 中管理。身份联合到外部身份管理系统。 在 IAM 外部管理。身份联合到外部身份管理系统。
政策 明确列出权限的文档。 绑定列表。绑定会将成员列表绑定到某种角色。
政策附加 将政策附加到 IAM 用户、群组或资源。 将政策附加到资源。

政策评估 默认拒绝。 默认拒绝。
权限集合 政策 角色
预定义的一组权限 管理式政策 预定义角色
审核 IAM 调用 AWS CloudTrail 审核日志
版本控制

资源管理和封装

本节帮助您了解各个云提供商如何管理资源。

AWS 采用多个帐号

使用 AWS 时,最佳做法是为每个团队设置多个帐号。然后,您可以在每个帐号下分配权限和政策。您可以设置合并计费并实施 AWS Organizations,从而降低管理多个 AWS 帐号的复杂性。

在 Google Cloud 中组织项目和政策

Google Cloud 提供组织、文件夹和项目等容器资源,让您可以对 Pub/Sub 主题和 Compute Engine 虚拟机实例等其他 Google Cloud 资源进行分组和分层组织。这种分层整理方式让您可以管理资源的常见方面,例如访问权限控制与配置设置。

所有 Google Cloud 资源都属于一个项目资源,一个 Google 帐号可以管理多个项目。您可以单独管理这些项目。您可以将类似或相关项目分组到文件夹中进行管理。此外,您还可以同时管理组织资源下的文件夹和项目。

下图显示了一个示例,方便您了解 Google Cloud 中的各种资源及其分层组织。如要与大多数 Google Cloud 资源交互,您必须为每个请求提供标识性的项目信息。

Google Cloud 资源层次结构示例。

政策继承

使用 AWS 时,您可以指定基于资源的权限(直接应用于资源),也可以指定针对给定资源执行特定操作的权限。指定权限的方式取决于服务。

Google Cloud 的 IAM 政策继承由其资源的组织形式进行补充。在 Google Cloud 中,资源以分层方式进行组织,因此您可以设置从组织节点开始向下层延伸的 IAM 政策。如果您希望拥有组织范围的 IAM 政策,则可以针对组织资源分配这些政策。如果要跨多个团队和项目设置政策,则可以使用 Google Cloud 文件夹来执行此操作。然后,您可以在项目级分配权限,最后在项目内的资源级分配权限以实现更精细的控制。

身份

用于访问云资源的身份分为两类:

  • 最终用户身份,用他们通常的公司登录名表示。在 AWS 中,最终用户还可以使用 IAM 帐号表示。
  • 编程身份,支持应用代码访问云资源。

AWS 中的最终用户身份

AWS 管理创建每个帐号所需的根帐号。AWS 提供了一系列最佳做法,帮助保护 AWS 帐号的根访问密钥。

如需允许用户访问您的 AWS 资源,您可以设置 IAM 用户,这些用户是在 AWS 中创建的身份,或者您可以从公司目录设置联合。您还可以使用第三方身份提供商。配置与 AWS 一起使用的第三方身份提供商时,您需要创建 IAM 角色,然后为该角色定义权限。当联合用户登录 AWS 时,该用户与该角色关联,并被授予该角色中定义的权限。

Google Cloud 中的最终用户访问权限

使用 Google Cloud 时,分配项目所有权的选择有两个:

  • 您可以将项目创建为具有一个或多个所有者,这些所有者都拥有对项目资源的完全访问权限。
  • 您可以将项目创建为没有明确所有者。当项目是组织的一部分并且您希望所有项目归该组织所有时,此方法非常有用。

IAM 不支持您管理最终用户身份;它支持您通过其他方式向您创建和管理的用户授予访问权限。使用 IAM 时,默认情况下您可以向以下类型的身份授予访问权限

  • Google 帐号
  • 服务帐号
  • Google 群组
  • Google Workspace 网域

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

如果您尚未使用 Google Workspace 网域来管理用户,则可以从许多常用用户目录(如 Active Directory)联合现有的操作用户子集。此方法允许您使用现有的公司身份。您必须先通过 Google 验证您的域名。

下表列出并描述了将用户联合到 Google Cloud 的方法。

联合技术 说明
Cloud Directory Sync Google 提供的工具,可与大多数商业和企业 LDAP 目录服务搭配使用。借助 Cloud Directory Sync,您可以添加、修改和删除用户、群组和非员工联系人,以使用 LDAP 查询将 Google Cloud 网域中的数据与 LDAP 目录服务器同步。您的 LDAP 目录服务器中的数据绝不会被修改或盗用。
第三方身份连接器 某个身份提供商的原生连接器,专门用于提供该连接器的机构。直接将身份提供商连接到 Google Cloud 中预配的网域。例如:

  • Ping Federate
  • Okta
  • CA Siteminder
  • Azure AD
  • OpenIAM
  • Auth0
  • Oracle IAM
Google Apps API 为组织提供编程用户和群组管理控制。

然后,您可以电子邮件地址的形式将身份添加到 Google 群组中,以向其授予访问 Google Cloud 资源的权限。

AWS 中的编程身份

使用 AWS 时,如果要通过未在 AWS 计算资源上运行的应用调用 AWS API,则需要创建 IAM 用户。然后,您下载相应的密钥并同时利用您的应用进行 AWS API 调用。

如果要在 EC2 实例上使用编程身份,您还必须创建实例配置文件并添加到实例中。此配置文件包含 IAM 角色,它可以将该角色的凭据提供给在实例上运行的应用。

IAM 角色允许 IAM 用户、群组或可以在 EC2 或移动设备上运行的应用承担该角色定义的权限。系统创建临时凭据并将其提供给担任该角色的实体。

使用 IAM 角色还允许 IAM 用户切换到某个角色,以便在使用控制台时临时使用该角色的权限。这种情况下,用户会放弃其原始权限并获取分配给该角色的权限。当用户退出该角色时,会放弃这些权限。

Google Cloud 中的编程身份

使用 Google Cloud 时,服务帐号是一种特殊的 Google 帐号,应用可使用它以编程方式访问 Google 服务。此帐号属于您的应用或 Compute Engine 实例,而非某个最终用户。

服务帐号可以包含成对的服务帐号密钥,用于向 Google 进行身份验证。服务帐号密钥是由 Google 生成的公钥 - 私钥对。Google 会保留公钥,同时将私钥提供给用户。

您可以使用 Google Cloud Console、Identity and Access Management API 或 gcloud 命令行工具在 Google Cloud 项目中创建自定义服务帐号。

如果您只打算将该服务帐号与在 Google Cloud 计算服务上运行的应用配合使用,则无需下载私钥,因为您可以使用由 Google Cloud 管理的密钥。

IAM 服务帐号的一个特性是您可以将其视为资源或身份。服务帐号具有一种身份,您可以通过向其授予可访问资源(例如项目)的角色来授予它权限。

将服务帐号视为资源时,您可以像向其他 Google Cloud 资源授予访问权限一样向用户授予访问该服务帐号的权限。您可以向用户授予 Owner、Editor、Viewer 或 serviceAccountUser 未定义角色以访问服务帐号。具有服务帐号 serviceAccountUser 的用户可以访问该服务帐号有权访问的所有资源。该功能与上一节所述 IAM 角色的用法类似。

服务帐号密钥可以是由用户管理的密钥,也可以是由 Google Cloud 管理的密钥

您可以使用 Cloud Console、IAM API 或 gcloud 命令行工具创建和管理用户管理的密钥。您需要确保密钥安全并轮替它们。

App Engine 和 Compute Engine 等服务使用 Google Cloud 管理的密钥。您无法显式创建或下载 Google Cloud 管理的密钥;Google 将管理这些密钥,并每天为您轮替一次。

权限归因

Google Cloud 和 AWS 都使用术语“角色”和“政策”,但用法稍有差异。这些差异可能会引起 AWS IAM 与 IAM 的对应混乱。Google Cloud 中的权限集合称为角色,但在 AWS 中则称为政策。

AWS 权限示例

使用 AWS 时,您在政策定义中将权限指定为操作、资源和效果。例如,允许(效果)某个人列出(操作)帐号(资源)中的所有存储分区的 AWS 政策如下所示:

{
  "Version": "2012-10-17",
  "Statement": {
  "Effect": "Allow",
  "Action": "s3:ListAllMyBuckets",
  "Resource": "*"
  }
}

可以添加到多个用户、群组和角色的独立 AWS IAM 政策称为管理式政策。代管式政策要么是由 AWS 创建和管理的 AWS 代管式政策,要么是您在 AWS 帐号中创建和管理的客户代管式政策。

Google Cloud 权限示例

Google Cloud 具有预定义的角色优先方案,因此诸如列出项目中所有存储分区等常见用例只需使用 Viewer 角色即可做到。然后您需要将此角色分配给用户或群组,随之会产生将用户或群组绑定到该角色的文档,该文档就称为政策。政策的定义类似于以下示例:

{
  "bindings": [
      {
     "role": "roles/viewer",
     "members": ["group:gcs-viewers@example.com"]
   }
  ]
}

AWS 政策

使用 AWS 时,除了能够向身份附加政策外,您还可以向资源附加政策。如果是附加到资源的政策,您需要在政策中嵌入能够访问该资源的身份或角色。

大多数情况下,AWS 建议使用代管式政策。在代管式政策与内嵌政策之间该如何选择呢?如需了解相关建议,请参阅 AWS 文档

Google Cloud 政策

现在我们来看一下 JSON 文件中声明的 Google Cloud 政策,该政策名为 iam-gcs-access.json,,将 viewer 角色授予一组用户,并将 objectCreator 角色授予服务帐号。应用使用服务帐号将对象添加到项目中的存储分区。以下示例说明了如何在一个政策中创建多个成员到角色的绑定。

{
    "bindings": [
    {
        "members": [
            "group:gcs-viewers@example.com"
        ],
        "role": "roles/viewer"
    },
    {
        "members": [
            "serviceAccount:123456789012-compute@developer.gserviceaccount.com"
        ],
        "role": "roles/storage.objectCreator"
    },
    ],
    "etag": "BwUjMhCsNvY=",
    "version": 1
}

然后,您可以使用 Cloud Console、gcloud 工具中的 set-iam-policy 命令或 API 将此政策绑定到资源(在本例中为项目),以将政策分配给项目。对于此示例,gcloud 命令如下所示:

gcloud projects set-iam-policy [PROJECT_ID] iam-gcs-access.json

其中 [PROJECT_ID] 表示您的 Google Cloud 项目 ID。

这类似于您在 AWS 政策中嵌入能够访问资源的身份或角色的方式。

在 Google Cloud 中管理政策

您应该像处理代码那样处理政策:将它们与您用于定义云环境的其他资产一起保存在版本控制系统中。如果您更新政策,则会创建新版本。

虽然 AWS 具有上文所述的两种政策,但 Google Cloud 只有一种政策,您可以灵活地使用您认为合适的任何版本控制系统来管理政策。Google Cloud 提供 Cloud Source Repositories,这是一个托管在 Google Cloud 上且功能齐全的专用 Git 代码库。

如果您已在 GitHub 或 Bitbucket 上拥有代码库,则可以将其连接到您的 Cloud Source Repositories。连接的代码库和 Cloud Source Repositories 保持自动同步。此外,Cloud Source Repositories 还提供了一个源编辑器,您可以使用该编辑器从 Cloud Console 浏览、查看、修改和提交对代码库文件所做的更改。

如果您更喜欢自己目前的版本控制解决方案,可以在 Google Cloud 上继续使用。

测试和检查权限

使用 AWS 时,您可以使用 IAM 政策模拟器,以便测试及验证任何新政策和现有政策,并查看用户、群组或资源已设置的政策。

使用 Google Cloud 时,您可以使用 get-iam-policy gcloud 命令返回政策定义:

gcloud projects get-iam-policy [PROJECT_ID]

您可以使用返回的定义来帮助检查附加到资源的政策。您还可以使用 Cloud Console 访问特定资源并检查权限。

如需检查分配给某个身份的权限,您可以在 Cloud Console 中选择该身份并查看该身份绑定到的角色。您还能以该身份或具有相同权限的测试身份登录,以检查该身份可在 Cloud Console 中访问哪些内容。

权限传播

AWS 中的所有政策都可以进行评估。定义政策的顺序并没有明显的影响,因为最终结果要么是“允许”,要么是“拒绝”。通过使用显式拒绝,您可以替换可能允许访问大量资源的广泛政策。这在确定帐号中是允许还是拒绝请求中有详细描述。

使用 Google Cloud 时,资源的有效政策是指为该资源设置的政策与从其父级沿用而来的政策的集合。由于角色是同心的,向同一用户授予多个角色会使用户获得授予的最广泛角色的权限。如需了解一些示例场景,请参阅使用资源层次结构实现访问权限控制

IAM 审核

为了审核 IAM 活动,Amazon 提供了 AWS CloudTrail,用于记录您帐号的 AWS API 调用并形成日志。CloudTrail 将这些日志发送到您指定的 Amazon S3 帐号。

Google Cloud 提供了 Cloud Audit Logs,用于记录管理员活动和数据访问。这两个日志流由 Google Cloud 服务生成,可帮助您回答在 Google Cloud 项目中“哪些用户何时在何处执行过哪些操作?”这一问题。

各个审核日志条目会在 Google Cloud 的运维套件中保留一段指定的时间,因此您可以一目了然地在信息中心查看最近的活动。经过指定时间段以后,这些条目将从 Google Cloud 的运维套件中删除。Cloud Logging 配额政策说明了日志条目的保留时间长度。您无法以其他方式删除或修改审核日志。

记录 IAM 角色可让您限制访问权限,以仅允许对项目或组织中与日志记录相关的资源进行访问。

要延长保留期限,您可以将审核日志条目导出到 Cloud Storage 存储分区、BigQuery 数据集、Pub/Sub 主题或上述三者的任意组合中

后续步骤

查看其他“面向 AWS 专业人员的 Google Cloud”文章: