服务帐号既是身份，也是资源。由于服务帐号是资源，接受允许政策，因此您可以通过向其他主帐号授予服务帐号的角色来允许它们访问服务帐号。
本页面列出了您可以授予主帐号的角色，以便它们可以创建、管理或模拟服务帐号。管理服务帐号时，您需要查看、更新、删除、停用、启用和列出服务帐号以及管理其 IAM 政策。模拟服务帐号是指用户使用短期有效凭据通过服务帐号证明其身份的行为。该行为通常用于临时提升访问权限。如需详细了解服务帐号模拟，请参阅服务帐号模拟。
本页面还介绍了在某些常见场景中使用服务帐号所需的权限。
服务帐号角色
您可以向主帐号授予以下角色，以允许它们管理或模拟服务帐号。
如需了解如何向用户授予这些角色，请参阅以下内容：
- 如需了解如何允许用户管理或模拟单个服务帐号，请参阅管理对服务帐号的访问权限。
- 如需了解如何允许用户管理或模拟项目中的所有服务帐号，请参阅管理对项目、文件夹和组织的访问权限。
服务帐号用户角色
Service Account User 角色 (roles/iam.serviceAccountUser) 包含 iam.serviceAccounts.actAs 权限，此权限允许主帐号间接访问服务帐号可访问的所有资源。例如，如果某个主帐号具有一个服务帐号的 Service Account User 角色，而该服务帐号具有项目的 Cloud SQL Admin 角色 (roles/cloudsql.admin)，那么该主帐号便可以模拟该服务帐号来创建 Cloud SQL 实例。
此角色还允许主帐号将服务帐号关联到资源。
此角色不允许主帐号为服务帐号创建短期有效凭据，或将 --impersonate-service-account 标志用于 Google Cloud CLI。要完成这些任务，您还需要 Service Account Token Creator 角色。
Service Account Token Creator 角色
此角色允许主帐号模拟服务帐号来执行以下操作：
- 创建 OAuth 2.0 访问令牌，您可以使用该令牌向 Google API 进行身份验证
- 创建 OpenID Connect (OIDC) ID 令牌
- 对 JSON Web 令牌 (JWT) 和二进制 blob 进行签名，以便它们可以用于身份验证
如需了解详情，请参阅创建短期有效的服务帐号凭据。
此角色的权限包括：
iam.serviceAccounts.getAccessToken：允许您创建 OAuth 2.0 访问令牌iam.serviceAccounts.getOpenIdToken：允许您创建 OpenID Connect (OIDC) ID 令牌iam.serviceAccounts.implicitDelegation：允许服务帐号在委托链中获取令牌iam.serviceAccounts.signBlob：允许您为二进制 blob 签名iam.serviceAccounts.signJwt：允许您为 JWT 签名
Workload Identity User 角色
此角色允许主帐号模拟 GKE 工作负载中的服务帐号。
此角色的权限包括：
iam.serviceAccounts.getAccessToken：允许您创建 OAuth 2.0 访问令牌iam.serviceAccounts.getOpenIdToken：允许您创建 OpenID Connect (OIDC) ID 令牌
针对常见场景的服务帐号权限
服务帐号可用于许多不同的场景，每个场景都需要特定权限。本部分介绍了常见场景以及需要哪些权限。
将服务帐号附加到资源
如果您要启动以服务帐号的身份进行身份验证的长时间运行作业，则需要将服务帐号附加到将运行该作业的资源。
权限：
- 创建资源的权限
iam.serviceAccounts.actAs
如需查找包含这些权限的角色，请在角色列表中搜索权限。
能够以服务帐号的身份运行长时间运行作业的不同 Google Cloud 资源有若干种。这些资源的一些示例包括：
- Compute Engine 虚拟机
- App Engine 应用
- Cloud Functions
创建这些资源时，您可以选择附加服务帐号。此服务帐号充当资源的身份。
如需创建资源并附加服务帐号，您需要具备创建该资源的权限以及模拟您将附加到该资源的服务帐号的权限。模拟服务帐号的权限由包含 iam.serviceAccounts.actAs 权限的任何角色提供。
创建资源并将服务帐号附加到该资源后，您可以在该资源上启动长时间运行的作业。该作业以附加到该资源的服务帐号身份运行，并使用该服务帐号为发送到 Google Cloud API 的请求授权。
如需详细了解如何将服务帐号附加到资源，请参阅将服务帐号附加到资源。
直接模拟服务帐号
权限：
iam.serviceAccounts.getAccessTokeniam.serviceAccounts.signBlobiam.serviceAccounts.signJwtiam.serviceAccounts.implicitDelegation
角色：
roles/iam.serviceAccountTokenCreator(Service Account Token Creator)
用户（或服务）获得所需权限后，可在几种常见场景下直接模拟（或断言）服务帐号的身份。
首先，用户可以使用 iam.serviceAccounts.getAccessToken 权限并调用 generateAccessToken() 方法来获取服务帐号的短期凭据。使用短期凭据，用户可向 Google Cloud 发出命令，并且可以访问服务帐号有权访问的所有资源。例如，该流程使用户可以使用 gcloud --impersonate-service-account 标志来模拟服务帐号，而无需使用下载的外部服务帐号密钥。
其次，用户可以使用 iam.serviceAccounts.signBlob 权限并通过调用 signBlob() 或 signJwt() 方法获得由服务帐号的 Google 管理的私钥签名的工件。由 Google 管理的私钥始终由第三方托管，且不会直接公开。signBlob() 允许对任意负载签名（例如通过 Cloud Storage 签名的网址），而 signJwt() 仅允许对格式正确的 JWT 签名。
最后，用户可以模拟（或断言）服务帐号，而无需检索服务帐号的凭据。这是一种高级用例，仅支持使用 generateAccessToken() 方法进行编程式访问。在包含至少 3 个服务帐号（即 A、B 和 C）的场景中：如果向服务帐号 A 授予对 B 的 iam.serviceAccounts.implicitDelegation 权限，向 B 授予对 C 的 iam.serviceAccounts.getAccessToken 权限，则服务帐号 A 可以获取服务帐号 C 的访问令牌。
生成 OpenID Connect (OIDC) ID 令牌
权限：
iam.serviceAccounts.getOpenIdToken
角色：
roles/iam.serviceAccountTokenCreator(Service Account Token Creator)
用户（或服务）可以生成一个与 OpenID Connect (OIDC) 兼容的 JWT 令牌，该令牌由 Google OIDC 提供商 (accounts.google.com) 签名，代表使用 iam.serviceAccounts.getOpenIdToken 权限的服务帐号的身份。
如果您的组织没有部署其他用于授予 Google 访问权限的身份联合系统，则大部分 Google API 都不会直接接受这些令牌。但存在少数例外情况，例如 Identity-Aware Proxy，它允许基于 OIDC 访问用户运行的应用。
生成外部私钥
权限：
iam.serviceAccountKeys.create
角色：
roles/editor(Editor)roles/iam.serviceAccountKeyAdmin(Service Account Key Admin)
用户或服务可以生成外部私钥材料 (RSA)，RSA 可用作服务帐号直接向 Google 进行身份验证。此密钥材料随后可用于应用默认凭据 (ADC) 库或 gcloud auth
activate-service-account 命令。任何获得密钥材料访问权限的用户都可以拥有该服务帐号有权访问的所有资源的完全访问权限。此类私钥材料应受到高度重视，材料存在的时间越长，就越不安全。因此，轮替私钥材料对于保持较高的安全性来说至关重要。
授予服务帐号角色的最佳做法
如果某个服务帐号获得了可执行高级特权操作的权限，则在向用户授予该服务帐号的 Service Account User 角色时必须小心谨慎。
服务帐号代表您的服务级安全性。服务的安全性取决于具有管理和使用服务帐号的 IAM 角色的人员，以及为这些服务帐号保留服务帐号密钥的人员。确保安全性的最佳实践包括：
- 使用 IAM API 审核服务帐号、密钥和这些服务帐号的允许政策。
- 如果您的服务帐号不需要服务帐号密钥，请停用或删除它们。
- 如果用户不需要管理或使用服务帐号的权限，请将其从适用的允许政策中移除。
- 确保服务帐号拥有尽可能少的权限。请谨慎使用默认服务帐号，因为系统会自动向其授予项目的 Editor (
roles/editor) 角色。
如需详细了解最佳实践，请参阅使用服务帐号的最佳实践。