服务账号

本页面介绍服务账号如何与 Compute Engine 搭配工作。

如需了解将服务账号关联到虚拟机 (VM) 实例的分步说明，请参阅以下文档之一：

如需了解创建和管理服务账号的最佳实践，请参阅使用服务账号的最佳实践文档。

自行试用

如果您是 Google Cloud 新手，请创建一个账号来评估 Compute Engine 在实际场景中的表现。新客户还可获享 $300 赠金，用于运行、测试和部署工作负载。

免费试用 Compute Engine

什么是服务账号?

服务账号是由应用或计算工作负载（而非真人）使用的特殊账号。服务账号由 Identity and Access Management (IAM) 管理。

将服务账号用于虚拟机时，请注意以下几点：

  • 您可以将同一服务账号关联到多个虚拟机，但一个虚拟机只能关联一个服务账号。
  • 如果您将同一服务账号关联到多个虚拟机，则您对该服务账号所做的任何后续更改都会影响使用该服务账号的所有虚拟机。这包括您对授予服务账号的 IAM 角色所做的任何更改。 例如，如果移除一个角色，则使用该服务账号的所有虚拟机都将失去该角色授予的权限。

Compute Engine 如何使用服务账号

Compute Engine 使用两种类型的服务账号：

可以将用户管理的服务账号关联到 Compute Engine 实例，以便为该实例上运行的应用提供凭据。应用使用这些凭据向 Google Cloud API 进行身份验证，以及获取访问 Google Cloud 资源的授权。只有用户管理的服务账号才能关联到实例，并且一个实例只能关联一个服务账号。您可以在创建时或稍后更改关联到实例的服务账号。

实例使用服务代理代表您访问内部进程。

此外，您还可以创建防火墙规则，按照与每个实例相关联的服务账号来允许或拒绝传入和传出实例的流量。

如何确定授权

向 Compute Engine 实例上托管的应用提供的授权会受到以下两个单独配置的限制：授予关联的服务账号的角色以及您在实例上设置的访问权限范围。这两种配置都必须允许访问，然后实例上运行的应用才能访问资源。

假设您的应用需要在 Cloud Storage 上读取和写入文件的应用，它必须首先向 Cloud Storage API 进行身份验证。您可以使用 cloud-platform 范围创建实例，并将服务账号关联到该实例。然后，您可以向服务账号授予 Identity and Access Management (IAM) 角色，以便向您的应用授予对相应资源的访问权限。您的应用使用服务账号凭据向 Cloud Storage API 进行身份验证，无需在实例、映像或应用代码中嵌入任何密钥或用户凭据。您的应用也会使用服务账号的 IAM 角色提供的授权来访问资源。如需详细了解授权，请参阅本页面上的授权。

用户管理的服务账号

用户管理的服务账号包括您明确创建的新的服务账号和 Compute Engine 默认服务账号。

新服务账号

您可以使用 IAM 创建和管理自己的服务账号。在您创建了某个账号后，需要向该账号授予 IAM 角色，并将实例设置为以该服务账号的身份运行。在关联了服务账号的实例上运行的应用可以使用该账号的凭据向其他 Google API 发出请求。

如需创建和设置新的服务账号，请参阅创建使用用户管理的服务账号的虚拟机。

Compute Engine 默认服务账号

已启用 Compute Engine API 的新项目都有一个 Compute Engine 默认服务账号，该账号具有以下电子邮件：

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Compute Engine 默认服务账号具有以下属性：

  • 自动创建，具有自动生成的名称和电子邮件地址，并在启用 Compute Engine API 时添加到项目。 您可以完全控制此账号。
  • 默认情况下关联到您使用 Google Cloud CLI 或 Google Cloud 控制台创建的所有虚拟机。您可以替换此行为，方法是在创建虚拟机时指定其他服务账号，或明确指定不将任何服务账号关联到该虚拟机。

  • 根据您的组织政策配置，默认服务账号可能会自动被授予项目的 Editor 角色。我们强烈建议您通过强制执行 iam.automaticIamGrantsForDefaultServiceAccounts 组织政策限制条件来停用自动角色授予功能。如果您的组织是在 2024 年 5 月 3 日之后创建的，则默认情况下会强制执行此限制条件。

    如果您停用自动角色授予功能，则必须决定向默认服务账号授予哪些角色，然后自行授予这些角色。

    如果默认服务账号已具有 Editor 角色，我们建议您将 Editor 角色替换为权限较少的角色。如需安全地修改服务账号的角色，请使用 Policy Simulator 查看更改的影响，然后授予和撤消相应的角色。

您可以从项目中停用或删除此服务账号，但这样做可能会导致依赖于该服务账号的凭据的任何应用运行失败。如果您不小心删除了 Compute Engine 默认服务账号，可以尝试在 30天内恢复该账号。如需了解详情，请参阅删除和恢复删除的服务账号。

如果 Compute Engine 默认服务账号已被删除超过 30 天，您可以尝试按照排查默认服务账号问题中的流程来恢复服务账号。

服务代理

服务代理由 Google Cloud 创建和管理，会自动分配给您的项目。这些账号代表不同的 Google Cloud 服务，每个账号通常都对您的 Google Cloud 资源拥有某种级别的访问权限。

您无法将服务代理连接到 Compute Engine 实例。

Google API 服务代理

除默认服务账号外，所有启用了 Compute Engine 的项目都附带有一个 Google APIs Service Agent，该代理采用了如下电子邮件地址形式：

PROJECT_NUMBER@cloudservices.gserviceaccount.com

此服务代理专门用于代表您运行内部 Google 进程。此服务代理为 Google 拥有，并未在 Google Cloud 控制台的服务账号部分中列出。默认情况下，此服务代理会自动获得项目的 Editor 角色，并在 Google Cloud 控制台的 IAM 部分中列出。只有在删除该项目后，才会删除此服务代理。但是，您可以更改已授予此账号的角色，包括撤消对您项目的所有访问权限。

某些资源依赖于向此服务代理授予的默认 Editor 权限。例如，托管式实例组和自动扩缩功能使用此服务代理的凭据来创建、删除和管理实例。如果您撤消此服务代理的权限，或者以未授予创建实例的权限的方式修改权限，这会导致托管式实例组和自动扩缩功能停止工作。

出于这些原因，除非角色建议明确建议您修改此服务代理的角色，否则不应进行修改。

Compute Engine Service Agent

所有启用了 Compute Engine API 的项目都有一个 Compute Engine Service Agent，该代理具有以下电子邮件：

service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com

此服务代理专为 Compute Engine 在您的项目中执行其服务任务而设计。它依赖于您的 Google Cloud 项目上授予的服务代理 IAM 政策。它也是 Compute Engine 用于访问虚拟机实例上用户管理的服务账号的服务代理。此账号为 Google 拥有，但专供您的项目使用。除非您选择包含 Google 提供的角色授权，否则此服务代理会在控制台的 IAM 页面中隐藏。默认情况下，此服务代理会自动获得项目的 compute.serviceAgent 角色。

只有在您删除项目时，系统才会删除此服务代理。您可以更改向此服务代理授予的角色，也可以撤消此代理对项目的所有访问权限。撤消或更改此服务代理的权限会导致 Compute Engine 无法访问您的虚拟机上的服务账号的身份，并可能导致在虚拟机内运行的软件中断。

由于这些原因，您应该尽可能避免修改此服务代理的角色。

将服务账号附加到实例

为避免向应用提供过多权限，我们建议您创建一个用户管理的服务账号，仅向其授予应用正常运行所需的角色，并将其关联到您的 Compute Engine 实例。然后，您的代码可以使用应用默认凭据通过该服务账号提供的凭据进行身份验证。

您可以在创建 Compute Engine 实例时或之后将服务账号关联到实例。一个实例一次只能关联一个服务账号；如果您将服务账号关联到已关联服务账号的实例，则该实例将不再使用之前的服务账号。

将服务账号关联到 Compute Engine 实例时，还必须确保实例上设置的范围正确无误。否则，您的应用可能无法访问其需要的所有 API。如需了解详情，请参阅本页面上的访问权限范围。

如需了解将服务账号关联到 Compute Engine 实例的分步说明，请参阅以下文档之一：

授权

在设置要以服务账号的身份运行的实例时，您可以通过授予该服务账号的 IAM 角色确定服务账号的访问权限级别。如果服务账号没有 IAM 角色，则无法使用该实例上的服务账号访问资源。

此外，针对通过 gcloud CLI 和实例上的客户端库发出的请求，实例的访问权限范围决定了其默认的 OAuth 范围。因此，通过 OAuth 进行身份验证时，访问权限范围可能会进一步限制对 API 方法的访问权限，但不会扩展到其他身份验证协议（如 gRPC）。

最佳实践是在实例上设置完整的 cloud-platform 访问权限范围，然后使用 IAM 角色控制服务账号的访问权限。

实质上来讲：

  • IAM 根据授予该服务账号的 IAM 角色限制对 API 的访问权限。
  • 访问权限范围可能会进一步限制对 API 方法的访问权限。

以下部分详细介绍了访问权限范围和 IAM 角色。

IAM 角色

您必须向服务账号授予相应的 IAM 角色，该服务账号才能访问相关的 API 方法。

例如，您可以向服务账号授予 IAM 角色，以管理 Cloud Storage 对象和/或 Cloud Storage 存储桶，从而限定该账号拥有这些角色授予的权限。

将 IAM 角色授予某个服务账号后，在附加了该服务账号的实例上运行的任何应用都将具有该角色授予的权限。

注意事项：

  • 一些 IAM 角色处于 Beta 版阶段。

    如果您需要的访问权限级别没有预定义角色，您可以创建并授予自定义角色。

  • 您必须在实例上设置访问权限范围才能授予访问权限。

    虽然服务账号的访问权限级别是由授予该服务账号的角色决定的，但针对通过 gcloud CLI 和实例上的客户端库发出的请求，实例的访问权限范围决定了其默认的 OAuth 范围。因此，通过 OAuth 进行身份验证时，访问权限范围可能会进一步限制对 API 方法的访问权限。

访问权限范围

访问权限范围是为虚拟机实例指定授权的传统方法。它们定义来自 gcloud CLI 或客户端库的请求中使用的默认 OAuth 范围。访问权限范围不适用于使用 gRPC 发出的调用。

访问权限范围应用于每个虚拟机，并且仅在虚拟机的生命周期内有效。您可以在创建虚拟机时设置访问权限范围，也可以在现有虚拟机上更新访问权限范围。

通常，每个 API 方法的文档都会列出该方法所需的范围。例如，instances.insert 方法在其授权部分中提供了有效范围的列表。

如果您未对该服务账号所属的项目启用相关 API，那么访问权限范围将不起作用。例如，在虚拟机实例上授予 Cloud Storage 的访问权限范围后，只有对项目启用了 Cloud Storage API 时，实例才能调用 Cloud Storage API。

默认范围

当您创建新的 Compute Engine 实例时，系统会自动为该实例配置以下访问权限范围：

  • 对 Cloud Storage 的只读权限：
    https://www.googleapis.com/auth/devstorage.read_only
  • 记录 Compute Engine 日志的写入权限：
    https://www.googleapis.com/auth/logging.write
  • 将指标数据发布到您的 Google Cloud 项目的写入权限：
    https://www.googleapis.com/auth/monitoring.write
  • 对 Google Cloud Endpoints（Alpha 版）所需的 Service Management 功能的只读权限：
    https://www.googleapis.com/auth/service.management.readonly
  • 针对 Google Cloud Endpoints（Alpha 版）所需的 Service Control 功能的读/写权限：
    https://www.googleapis.com/auth/servicecontrol
  • 对 Cloud Trace 的写入权限允许虚拟机上运行的应用将跟踪记录数据写入项目。
    https://www.googleapis.com/auth/trace.append

范围最佳实践

您可以从多个访问权限范围中进行选择，但最佳实践是设置 cloud-platform 访问权限范围（这是 Google Cloud 服务的 OAuth 范围），然后向服务账号授予 IAM 角色，从而控制该服务账号的访问权限。

https://www.googleapis.com/auth/cloud-platform

范围示例

按照范围的最佳实践，如果您在实例上启用了 cloud-platform 访问权限范围，然后授予以下预定义 IAM 角色：

  • roles/compute.instanceAdmin.v1
  • roles/storage.objectViewer
  • roles/compute.networkAdmin

那么该服务账号只拥有这三种角色所包含的权限。尽管存在 Google Cloud 访问权限范围，但模拟该服务账号的应用无法执行这些角色之外的操作。

另一方面，如果您在实例上授予限制性更高的范围，例如 Cloud Storage 只读范围 (https://www.googleapis.com/auth/devstorage.read_only)，然后在服务账号中设置 roles/storage.objectAdmin 管理员角色，那么默认情况下，来自 gcloud CLI 和客户端库的请求将无法管理来自该实例的 Cloud Storage 对象，即使您向服务账号授予了 roles/storage.ObjectAdmin 角色也是如此。这是因为 Cloud Storage 只读范围不会授予实例处理 Cloud Storage 数据的权限。

访问权限范围的示例包括：

  • https://www.googleapis.com/auth/cloud-platform。查看和管理指定 Google Cloud 项目中 Google Cloud 服务的数据。
  • https://www.googleapis.com/auth/compute - 对 Compute Engine 方法的完全控制权限。
  • https://www.googleapis.com/auth/compute.readonly - 对 Compute Engine 方法的只读权限。
  • https://www.googleapis.com/auth/devstorage.read_only - 对 Cloud Storage 的只读权限。
  • https://www.googleapis.com/auth/logging.write - 对 Compute Engine 日志的写入权限。

后续步骤