服务帐号

本页面介绍了服务帐号、服务帐号的类型以及适用于服务帐号的 IAM 角色。

准备工作

  • 了解 IAM 的基本概念。

什么是服务帐号?

服务帐号是由应用或虚拟机 (VM) 实例(而非单个用户)使用的特殊帐号。应用使用服务帐号来执行已获授权的 API 调用(以服务帐号本身的身份授权或者以 Google Workspace 或 Cloud Identity 用户的身份通过全网域授权功能授权)。

例如,Compute Engine 虚拟机可以以服务帐号的身份运行,该帐号可被授予访问其所需资源的权限。这样,服务帐号就是相应服务的标识,服务帐号的权限用于控制可以访问该服务的资源。

服务帐号由其电子邮件地址(对该帐号是唯一的)标识。

服务帐号与用户帐号之间的区别

服务帐号与用户帐号之间主要存在以下几大区别:

  • 服务帐号没有密码,无法通过浏览器或 Cookie 登录。
  • 服务帐号与用于向 Google 进行身份验证的 RSA 私钥/公钥对相关联。
  • 您可以允许其他用户或服务帐号模拟服务帐号。
  • 与用户帐号不同,服务帐号不是 Google Workspace 网域的成员。例如,如果您与 Google Workspace 网域中的所有成员共享资源,则无法与服务帐号共享这些资源。同样,服务帐号创建的任何资源也不能由 Google Workspace 或 Cloud Identity 管理员拥有或管理。使用全网域授权功能时,这一点不适用,因为 API 调用是以模拟用户(而不是服务帐号本身)的身份授权的。

服务帐号密钥

每个服务帐号都与用于向 Google 进行身份验证的两组 RSA 公钥/私钥对相关联:Google 管理的密钥和用户管理的密钥。

Google 管理的密钥

Google 管理的密钥对意味着 Google 存储密钥的公开和私有部分,并定期对它们进行轮替(密钥用于签名,每个密钥最多使用两周时间),而私钥始终由第三方托管,永远不能直接访问。IAM 提供可使用这些密钥代表服务帐号进行签名的 API。如需了解详情,请参阅创建短期有效的服务帐号凭据

用户管理的密钥

用户管理的密钥对意味着您同时拥有密钥对的公开和私有部分。您能够创建一个或多个可在 Google Cloud 外部使用的用户管理的密钥对(也称为“外部”密钥)。Google 只存储用户管理的密钥的公开部分。

此外,您还可以使用相应的格式创建公钥并将公钥上传到 Google,此公钥会在 Google 与指定的服务帐号永久关联。如果您需要代表该服务帐号执行签名操作(比方说创建服务帐号密钥时),系统就会使用上传的公钥。

用户管理的密钥对的私有部分最常与应用默认凭据一起使用。该私钥之后可用于对服务器至服务器的应用进行身份验证。

对于用户管理的密钥,您要负责确保私钥和其他管理操作(如密钥轮替)的安全性。您可以通过 IAM API、gcloud 命令行工具或 Google Cloud Console 中的“服务帐号”页面管理用户管理的密钥。您可以为每个服务帐号创建最多 10 个服务帐号密钥,以方便密钥轮替。

请考虑使用 Cloud Key Management Service (Cloud KMS) 来安全地管理您的密钥。

防止用户管理的密钥泄露

用户管理的密钥是非常强大的凭据,如果管理不正确,就可能面临安全风险。

您可对项目、文件夹,甚至整个组织应用 constraints/iam.disableServiceAccountKeyCreation 组织政策限制,以限制此类密钥的使用。应用此限制后,您可以在控制良好的位置启用用户管理的密钥,从而最大限度地降低不受管理的密钥所造成的潜在风险。

服务帐号的类型

用户管理的服务帐号

您可以使用 IAM API、Cloud Console 或 gcloud 命令行工具在项目中创建用户管理的服务帐号。您负责管理和保护这些帐号。

默认情况下,您可以在一个项目中最多创建 100 个用户管理的服务帐号。如果此配额不能满足您的需求,您可以使用 Cloud Console 申请增加配额。本页面介绍的默认服务帐号不计入此配额。

在项目中创建用户管理的服务帐号时,请选择服务帐号的名称。此名称显示在用于标识服务帐号的电子邮件地址中,该地址采用以下格式:

service-account-name@project-id.iam.gserviceaccount.com

默认服务帐号

如果您使用某些 Google Cloud 服务,这些服务会创建用户管理的服务帐号,以使该服务能够部署可访问其他 Google Cloud 资源的作业。这些帐号称为默认服务帐号

默认服务帐号可帮助您开始使用 Google Cloud 服务。对于生产工作负载,我们强烈建议您创建专属的用户管理的服务帐号,并向每个服务帐号授予适当的角色。

创建默认服务帐号后,系统会自动向其授予项目的 Editor 角色 (roles/editor)。此角色包含大量权限。为了遵循最低权限原则,我们强烈建议您通过向组织政策添加限制条件或手动撤消 Editor 角色来停用自动角色授予。如果您停用或撤消角色授予,则必须决定向默认服务帐号授予哪些角色。

下表列出了可创建默认服务帐号的服务:

服务 服务帐号名称 电子邮件地址
App Engine 以及任何使用 App Engine 的 Google Cloud 服务 App Engine 默认服务帐号 project-id@appspot.gserviceaccount.com
Compute Engine 以及任何使用 Compute Engine 的 Google Cloud 服务 Compute Engine 默认服务帐号 project-number-compute@developer.gserviceaccount.com

Google 管理的服务帐号

某些 Google Cloud 服务需要访问您的资源才能代表您执行操作。例如,当您使用 Cloud Run 运行容器时,服务需要访问所有可触发容器的 Pub/Sub 主题。

为了满足这一需求,Google 会为许多 Google Cloud 服务创建和管理服务帐号。这些服务帐号称为 Google 管理的服务帐号。您可能会在项目的 IAM 政策和审核日志中看到 Google 管理的服务帐号。

例如:

  • Google APIs Service Agent。您的项目可能包含一个名为 Google APIs Service Agent 的服务帐号,其电子邮件地址采用以下格式:project-number@cloudservices.gserviceaccount.com

    该服务帐号代表您运行内部 Google 流程。它会自动获得项目的 Editor 角色 (roles/editor)。

  • Google 管理的服务帐号的角色管理员。您的 IAM 审核日志可能引用了服务帐号 service-agent-manager@system.gserviceaccount.com

    此服务帐号管理已授予其他 Google 管理的服务帐号的角色。它仅在审核日志中可见。

    例如,如果您使用新的 API,则 Google 可能会自动创建一个新的 Google 管理的服务帐号,并向该服务帐号授予针对项目的角色。如果授予这些角色,则系统会生成一个审核日志条目,其中显示 service-agent-manager@system.gserviceaccount.com 为项目设置了 IAM 政策。

  • 其他 Google 管理的服务帐号。您的项目可能包含其他代表各项服务执行操作的 Google 管理的服务帐号。这些服务帐号有时称为“服务代理”。角色可能会自动授予给这些服务代理;这些角色的名称通常以 serviceAgent 结尾。

    如需查看服务代理以及自动授予给每个服务代理的角色的完整列表,请参阅服务代理

服务帐号权限

除了作为身份之外,服务帐号也可作为附加了 IAM 政策的资源。这些政策决定了谁可以使用服务帐号。

例如,Alice 可能在服务帐号中具有 Editor 角色,而 Bob 可能在服务帐号中具有 Viewer 角色。这就像为任何其他 Google Cloud 资源授予角色一样。

创建默认的 Compute Engine 和 App Engine 服务帐号后,系统会为其授予项目的 Editor 角色,以便在应用或虚拟机实例中执行的代码具有必要的权限。在这种情况下,服务帐号是具有资源(项目)的 Editor 角色的身份。

如果您希望允许应用访问 Cloud Storage 存储分区,则可向(应用使用的)服务帐号授予读取 Cloud Storage 存储分区的权限。在这种情况下,服务帐号是您要授予其他资源(Cloud Storage 存储分区)的相关权限的身份。

Service Account User 角色

您可以在项目级为项目中的所有服务帐号授予 Service Account User 角色 (roles/iam.serviceAccountUser),也可以在服务帐号级授予该角色。

  • 通过将 Service Account User 角色授予某项目的用户,可让该用户有权访问该项目中的所有服务帐号(包括将来可能创建的服务帐号)。

  • 通过将 Service Account User 角色授予特定服务帐号的用户,可让该用户只有权访问该服务帐号。

在服务帐号中具有 Service Account User 角色的用户可以用其间接访问该服务帐号有权访问的所有资源。例如,如果某个服务帐号具有 Compute Admin 角色 (roles/compute.admin),则该服务帐号上具有 Service Account User 角色 (roles/iam.serviceAccountUser) 的用户可以该服务帐号的身份启动 Compute Engine 实例。在此流程中,用户会模拟该服务帐号,使用其获得的角色和权限执行任何任务。

如需详细了解如何对服务帐号授予用户角色,请参阅管理服务帐号模拟

服务帐号代表您的服务级安全性。服务的安全性取决于具有 IAM 角色来管理和使用服务帐号的人员,以及为这些服务帐号保留私有外部密钥的人员。确保安全性的最佳做法包括:

  • 使用 IAM API 审核服务帐号、密钥和这些服务帐号的政策。
  • 如果您的服务帐号不需要外部密钥,请删除它们。
  • 如果用户不需要管理或使用服务帐号的权限,请将其从适用的 IAM 政策中移除。
  • 确保服务帐号拥有尽可能少的权限。请谨慎使用默认服务帐号,因为系统会自动向其授予项目的 Editor (roles/editor) 角色。

如需详细了解最佳做法,请参阅了解服务帐号

Service Account Token Creator 角色

此角色可以模拟服务帐号以创建 OAuth2 访问令牌、签署 Blob 或 JWT。

服务帐号操作者角色

此角色已弃用。如果您需要以服务帐号身份运行操作,请使用 Service Account User 角色。要有效地提供与 Service Account Actor 相同的权限,您还应授予 Service Account Token Creator 角色。

访问权限范围

访问权限范围是为虚拟机指定权限的传统方法。在 IAM 角色出现之前,访问权限范围是向服务帐号授予权限的唯一机制。尽管它们现在不是授予权限的主要方式,但在配置实例作为服务帐号运行时,您仍必须设置访问权限范围。要了解访问权限范围,请参阅 Google Compute Engine 文档

短期服务帐号凭据

您可以创建短期凭据,以获得 Google Cloud 服务帐号的身份。这些凭据可用于对 Google Cloud API 或其他非 Google API 调用进行身份验证。

这些凭据的最常见使用场景是临时委派访问权限以访问跨不同项目、组织或帐号的 Google Cloud 资源。例如,可向外部调用者授予临时紧急访问权限,而不是提供高权限服务帐号的永久性凭据。或者,外部调用者采用具有较少权限的指定服务帐号,而无需更高权限的服务帐号的凭据。

如需了解详情,请参阅创建短期服务帐号凭据

工作负载身份联合

您可以向 Google Cloud 外部(例如 Amazon Web Services (AWS) 或 Microsoft Azure)运行的工作负载的身份授予模拟服务帐号的权限。这样,您就可以使用短期凭据(而不是使用服务帐号密钥)直接访问资源。

如需了解详情,请参阅工作负载身份联合

应用默认凭据

应用默认凭据是一种机制,可让您在 Google Cloud 内部和外部以及跨多个 Google Cloud 项目进行操作时轻松使用服务帐号。最常见的使用场景是在本地机器上测试代码,再转移到 Google Cloud 中的开发项目,然后再转到 Google Cloud 中的生产项目。使用应用默认凭据可确保服务帐号无缝工作;它在本地机器上测试时使用本地存储的服务帐号密钥,但在 Compute Engine 上运行时使用项目的默认 Compute Engine 服务帐号。如需了解详情,请参阅应用默认凭据

后续步骤

要了解有关使用服务帐号的最佳做法,请参阅了解服务帐号

请阅读以下指南,了解如何: