主账号可以使用服务账号以几种不同的方式进行身份验证。每种身份验证类型都要求主账号拥有服务账号的特定 Identity and Access Management (IAM) 权限。
本页面介绍您可以为主账号授予的角色，以允许主账号模拟服务账号或将服务账号关联到资源。本页面还介绍了常见场景中所需的权限。
如需了解使用服务账号进行身份验证的不同方法，请参阅服务账号凭据和服务账号模拟。
服务账号角色
本部分介绍了可让主账号使用服务账号进行身份验证的角色。如需了解如何授予和撤消这些角色，请参阅管理对服务账号的访问权限。
服务账号用户角色
Service Account User 角色 (roles/iam.serviceAccountUser) 可让主账号将服务账号关联到资源。当该资源上运行的代码需要进行身份验证时，它可以获取关联服务账号的凭据。
此角色不允许主账号为服务账号创建短期有效凭据，也不允许主账号将 --impersonate-service-account 标志用于 Google Cloud CLI。如需完成这些任务，您需要服务账号的 Service Account Token Creator 角色。
Service Account Token Creator 角色
Service Account Token Creator 角色 (roles/iam.serviceAccountTokenCreator) 可让主账号为服务账号创建短期有效凭据。
Service Account Token Creator 角色可让您创建以下类型的短期有效凭据：
- OAuth 2.0 访问令牌，您可以使用该令牌向 Google API 进行身份验证
- OpenID Connect (OIDC) ID 令牌
- 已签名的 JSON Web 令牌 (JWT) 和二进制 blob
Service Account Token Creator 角色还允许主账号将 --impersonate-service-account 标志用于 gcloud CLI。使用此标志时，gcloud CLI 会自动为服务账号创建短期有效凭据。
此角色的权限包括：
iam.serviceAccounts.getAccessToken：可让您创建 OAuth 2.0 访问令牌iam.serviceAccounts.getOpenIdToken：允许您创建 OpenID Connect (OIDC) ID 令牌iam.serviceAccounts.implicitDelegation：允许服务账号在委托链中获取令牌iam.serviceAccounts.signBlob：允许您为二进制 blob 签名iam.serviceAccounts.signJwt：允许您为 JWT 签名
Service Account OpenID Connect Identity Token Creator
Service Account OpenID Connect Identity Token Creator 角色 (roles/iam.serviceAccountOpenIdTokenCreator) 可让主账号创建短期有效 OIDC ID 令牌。如果您只需要创建 OIDC ID 令牌，请使用此角色。如果您需要创建其他类型的令牌，请改为使用 Service Account Token Creator 角色。
该角色提供 iam.serviceAccounts.getOpenIdToken 权限，可让您创建 OIDC ID 令牌。
Workload Identity User 角色
Workload Identity User 角色 (roles/iam.workloadIdentityUser) 可让主账号从 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
创建这些资源时，您可以选择附加服务账号。此服务账号充当资源的身份。
如需创建资源并关联服务账号，您需要具备创建该资源的权限以及将服务账号关联到资源的权限。Service Account User 角色 (roles/iam.serviceAccountUser) 等任何角色提供的将服务账号关联到资源的权限，包括 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() 方法来获取服务账号的短期有效凭据。或者，他们可以使用 gcloud CLI 的 --impersonate-service-account 标志来模拟服务账号。当用户以服务账号身份进行身份验证时，可以向 Google Cloud 发出命令，并且可以访问服务账号有权访问的所有资源。
其次，用户可以使用 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.serviceAccountOpenIdTokenCreator(Service Account OpenID Connect Identity 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) 角色。
如需详细了解最佳实践，请参阅使用服务账号的最佳实践。