您可以将 Workload Identity Federation for GKE 与在 GKE 集群中运行的工作负载搭配使用，以向其授予访问 Google Cloud资源的权限。
Google Cloud 服务账号可充当生产环境中工作负载的身份。您需要为服务账号授予访问权限，然后让工作负载使用该服务账号作为其身份，而不是直接为工作负载授予访问权限。
通过托管式工作负载身份（预览版），您可以将经过严格证明的身份绑定到 Compute Engine 工作负载。您可以使用托管式工作负载身份通过 双向 TLS (mTLS) 向其他工作负载验证您的工作负载，但不能用于向 Google Cloud API 进行身份验证。
您可以为工作负载使用的身份类型以及配置方式取决于工作负载的运行位置。
Google Cloud上的工作负载
如果您是在 Google Cloud上运行工作负载，则可以使用以下方法为您的工作负载配置身份：
关联的服务账号
Workload Identity Federation for GKE（仅适用于在 Google Kubernetes Engine 上运行的工作负载）
托管式工作负载身份（仅适用于在 Compute Engine 上运行的工作负载）
服务账号密钥
关联的服务账号
对于某些 Google Cloud 资源，您可以指定用户管理的服务账号，供资源用作其默认身份。此过程称为“将服务账号关联到资源”或“将服务账号与资源关联”。当资源上运行的代码访问 Google Cloud 服务和资源时，它会使用关联到资源的服务账号作为其身份。例如，如果您将服务账号关联到某个 Compute Engine 实例，并且该实例上的应用使用客户端库来调用 Google Cloud API，则这些应用会自动使用关联的服务账号来进行身份验证和授权。
对于在 GKE 上运行的工作负载，借助 Workload Identity Federation for GKE，您可以为集群中的每个应用授予精细的 IAM 角色。借助 Workload Identity Federation for GKE，GKE 集群中的 Kubernetes 服务账号可以直接（通过使用员工身份联合）或间接（通过使用 IAM 服务账号模拟）访问 Google Cloud资源。
通过使用直接资源访问权限，您可以直接在 Google Cloud 服务的资源上向 Kubernetes 服务账号身份授予 IAM 角色。大多数 Google Cloud API 都支持直接资源访问。不过，使用身份联合时，某些 API 方法可能会受到限制。如需查看这些限制的列表，请参阅支持的产品和限制。
作为替代方案，工作负载还可以使用服务账号模拟，其中已配置的 Kubernetes 服务账号会绑定到 IAM 服务账号，该服务账号在访问 Google CloudAPI 时充当身份。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-18。"],[],[],null,["# Identities for workloads\n\nThis page describes the identity types that you can use to configure\nyour workloads' access to Google Cloud resources.\n\nGoogle Cloud provides the following types of identities for workloads:\n\n- [**Workload Identity Federation**](/iam/docs/workload-identity-federation) and\n [**Workload Identity Federation for GKE**](/kubernetes-engine/docs/concepts/workload-identity) let your workloads access\n most Google Cloud services by using federated identities that are\n authenticated through an external identity provider (IdP). After\n Google Cloud authenticates the identity as a principal, the principal\n can access resources by using IAM roles that you grant.\n\n- [**Google Cloud service accounts**](/iam/docs/service-account-overview) can act as\n identities for workloads in production environments. Instead of granting access\n to a workload directly, you grant access to a service account, then have the\n workload use the service account as its identity.\n\n- [**Managed workload identities**](/iam/docs/managed-workload-identity) [(Preview)](/products#product-launch-stages)\n let you bind strongly attested identities to your Compute Engine and\n GKE workloads.\n\nThe types of identities that you can use for workloads and the way that you\nconfigure them depends on where your workloads are running.\n\nConfigure workloads on Google Cloud\n-----------------------------------\n\nIf you're running workloads on Google Cloud, you can use the following\nmethods to configure identities for your workloads:\n\n- Attached service accounts\n- Workload Identity Federation for GKE (for workloads running on Google Kubernetes Engine only)\n- Managed workload identities (for workloads that run on Compute Engine and GKE only)\n- Service account keys\n\n### Attached service accounts\n\n\nFor some Google Cloud resources, you can specify a user-managed service account that the\nresource uses as its default identity. This process is known as *attaching* the service\naccount to the resource, or *associating* the service account with the resource.\n\n\nWhen code running on the resource accesses Google Cloud services and resources, it uses the\nservice account attached to the resource as its identity. For example, if you [attach a\nservice account to a Compute Engine instance](/compute/docs/access/service-accounts#associating_a_service_account_to_an_instance), and the applications on the instance use a [client library](/apis/docs/client-libraries-explained) to call Google Cloud APIs,\nthose applications automatically use the attached service account for authentication and\nauthorization.\n\nIn most cases, you must attach a service account to a resource when you create\nthat resource. After the resource is created, you cannot change which service\naccount is attached to the resource. Compute Engine instances are an\nexception to this rule; you can change which service account is attached to an\ninstance as needed.\n\nTo learn more, see [Attach a service account to a resource](/iam/docs/attach-service-accounts).\n\n### Workload Identity Federation for GKE\n\nFor workloads that run on GKE, Workload Identity Federation for GKE lets you\ngrant IAM roles to distinct, fine-grained sets of principals, for\neach application in your cluster. Workload Identity Federation for GKE lets Kubernetes\nservice accounts in your GKE cluster access Google Cloud\nresources directly, by using Workload Identity Federation, or indirectly,\nby using IAM service account impersonation.\n\nBy using direct resource access, you can grant IAM roles to the\nKubernetes service account identity directly on the Google Cloud service's\nresources. Most Google Cloud APIs support direct resource access. However,\nwhen using identity federation, certain API methods might have limitations. For\na list of these limitations, see [Supported products and limitations](/iam/docs/federated-identity-supported-services).\n\nAs an alternative, workloads can also use service account impersonation, where\nthe configured Kubernetes ServiceAccount is bound to an IAM\nservice account, which serves as the identity when accessing Google Cloud\nAPIs.\n\nTo learn more about GKE Workload Identity Federation for GKE, see\n[Workload Identity Federation for GKE](/kubernetes-engine/docs/concepts/workload-identity).\n\n### Managed workload identities\n\n|\n| **Preview**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the\n| General Service Terms section of the\n| [Service Specific Terms](/terms/service-terms#1).\n| Pre-GA features are available \"as is\" and might have limited support. For more\n| information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nManaged workload identities let you bind strongly attested identities to your\nCompute Engine and GKE workloads. You can use managed\nworkload identities to authenticate your workloads to other workloads using\n[mTLS](https://en.wikipedia.org/wiki/Mutual_authentication).\n\nTo learn more about managed workload identities, and how to configure platforms\nto use them, see [Managed workload identities overview](/iam/docs/managed-workload-identity).\n\nConfigure external workloads\n----------------------------\n\nIf you're running workloads outside of Google Cloud, you can use the\nfollowing methods to configure identities for your workloads:\n\n- Workload Identity Federation\n- Service account keys\n\n### Workload Identity Federation\n\nYou can use Workload Identity Federation with workloads on\nGoogle Cloud or external workloads that run on platforms such as AWS,\nAzure, GitHub, and GitLab.\n\nWorkload Identity Federation lets you use credentials from external identity\nproviders like [AWS, Azure](/iam/docs/workload-identity-federation-with-other-clouds), and [Active Directory](/iam/docs/workload-identity-federation-with-active-directory)\nto generate short-lived credentials, which workloads can use to temporarily\nimpersonate service accounts. Workloads can then access Google Cloud\nresources, using the service account as their identity.\n\nWorkload Identity Federation is the preferred way to configure identities for\nexternal workloads.\n\nTo learn more about Workload Identity Federation, see\n[Workload Identity Federation](/iam/docs/workload-identity-federation).\n\n### Service account keys\n\n\nA service account key lets a workload authenticate as a service account, then\nuse the service account's identity for authorization.\n| **Note:** Service account keys are a security risk if not managed correctly. You should [choose a more secure alternative to service account keys](/docs/authentication#auth-decision-tree) whenever possible. If you must authenticate with a service account key, you are responsible for the security of the private key and for other operations described by [Best practices for managing service account keys](/iam/docs/best-practices-for-managing-service-account-keys). If you are prevented from creating a service account key, service account key creation might be disabled for your organization. For more information, see [Managing secure-by-default organization resources](/resource-manager/docs/secure-by-default-organizations).\n|\n|\n| If you acquired the service account key from an external source, you must validate it before use.\n| For more information, see [Security requirements for externally sourced credentials](/docs/authentication/external/externally-sourced-credentials).\n\n\u003cbr /\u003e\n\nLocal development\n-----------------\n\nIf you're developing in a local environment, you can configure workloads to use\neither your user credentials or a service account for authentication and\nauthorization. For more information, see\n[Local development environment](/docs/authentication/set-up-adc-local-dev-environment) in the authentication documentation.\n\nWhat's next\n-----------\n\n- Learn how to [set up authentication by using service accounts](/docs/authentication#service-accounts).\n- Learn how to [set up authentication for a local development environment](/docs/authentication/set-up-adc-local-dev-environment).\n- Learn how to [grant service accounts access to resources](/iam/docs/granting-changing-revoking-access)."]]
