Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Mit Workload Identity können Sie jeder Anwendung in Ihrem Cluster separate, detaillierte Identitäten und Autorisierungen zuweisen. Workload Identity ist die empfohlene Methode für Anwendungen, die in GKE on AWS ausgeführt werden, um auf AWS- und Google Cloud -Dienste zuzugreifen.
Bei allen GKE-Clustern ist Workload Identity aktiviert.
Kubernetes-Dienstkonten
Workload Identity implementiert die Identitätsföderation oder das delegieren von Vertrauensstellungen oder Rollen an einen externen Anbieter. Jeder Cluster hat einen integrierten OIDC-Anbieter (Open ID Connect). Wenn ein Pod im Cluster ausgeführt wird, wird er mit einem Kubernetes-Dienstkonto ausgeführt.
Der Pod kann so konfiguriert werden, dass er mit einem gebundenen Dienstkonto-Token-Volume ein Token mit kurzlebigen Anmeldedaten für sein Kubernetes-Dienstkonto abruft.
Open ID Connect-Anbieter
Jeder Cluster kann als OIDC-Anbieter (Open ID Connect) fungieren. Mit diesem Anbieter können Sie Anmeldedaten für Kubernetes-Dienstkonto für Dienste bereitstellen, die die Identitätsföderation mit OIDC unterstützen.
Der Aussteller-URI dieses Anbieters dient auch als OIDC-Discovery-Endpunkt. Dienste können diesen Discovery-Endpunkt verwenden, um das JSON Web Key Set (JWKS) abzurufen. Dieses stellt Informationen zum öffentlichen Schlüssel bereit, mit denen sie die Anmeldedaten des Kubernetes-Dienstkontos überprüfen können.
Google Cloud IAM-Identitätspools und ‑Anbieter
Google Cloud IAM unterstützt die Identitätsföderation über OIDC.
Alle GKE-Cluster werden als Identitätsanbieter im Workload Identity-Pool PROJECT_ID.svc.id.goog konfiguriert.
IAM unterstützt die Identitätsföderation über OIDC.
Für den Zugriff auf AWS über die Dienstkontoidentitäten einer Arbeitslast müssen Sie einen OIDC-Anbieter in AWS IAM erstellen. Standardmäßig sind GKE on AWS-Cluster nicht mit einem Identitätsanbieter für AWS IAM konfiguriert.
Alternativen zu Workload Identity
Es gibt alternative Methoden, um von GKE on AWS auf Dienste zuzugreifen.
Die folgenden Methoden werden aufgrund von Komplikationen nicht empfohlen.
Anmeldedaten exportieren und als Kubernetes-Secrets speichern. In diesem Fall müssen Sie gespeicherte Anmeldedaten manuell in AWS IAM und in Ihrem Cluster rotieren. Wenn ein Angreifer Anmeldedaten stiehlt, kann er sie ausnutzen.
Anmeldedaten an die zugrunde liegenden Instanzen der Knotenpools anhängen. In diesem Fall werden die Anmeldedaten von allen Arbeitslasten, die auf demselben Knoten ausgeführt werden, gemeinsam genutzt. Dies kann zu mehr Berechtigungen führen, als Arbeitslasten benötigen. GKE-Cluster blockieren den Zugriff von einem Pod auf den Instanzmetadatendienst, um den Zugriff auf die Berechtigungen einer Instanz zu blockieren.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-07-31 (UTC)."],[],[],null,["# Workload identity overview\n\n*Workload identity* enables you to assign distinct, fine-grained identities and\nauthorization for each application in your cluster. Workload identity is the\nrecommended way for applications running within GKE on AWS to access\nAWS and Google Cloud services.\n\nAll GKE clusters have workload identity enabled.\n\nKubernetes service accounts\n---------------------------\n\nWorkload identity implements *identity federation* , or delegating trust or roles\nto an external provider. Each cluster has a built-in OpenID Connect (OIDC)\nprovider. When a Pod runs in the cluster, it runs using a\n[Kubernetes service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/).\nThe Pod can be configured to obtain a token with short-lived credentials for\nits Kubernetes service account using a\n[Bound Service Account Token Volume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume).\n\nOpenID Connect providers\n------------------------\n\nEach cluster can act as an\n[OpenID Connect (OIDC)](https://openid.net/connect/) provider. With\nthis provider, you can provide Kubernetes service account credentials to\nservices that support identity federation using OIDC.\n\nThis provider's issuer URI also serves as an OIDC discovery endpoint. Services\ncan use this discovery endpoint to obtain the JSON Web Key Set (JWKS), which\nprovides public key information that allows them to verify Kubernetes service\naccount credentials.\n\nGoogle Cloud IAM identity pools and providers\n---------------------------------------------\n\nGoogle Cloud IAM supports\n[identity federation using OIDC](https://cloud.google.com/iam/docs/workload-identity-federation).\nAll GKE clusters are configured as identity providers in the\nworkload identity pool \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e`.svc.id.goog`.\n\nTo get the name of your workload identity pool and providers, see\n[Use workload identity with Google Cloud](/kubernetes-engine/multi-cloud/docs/aws/how-to/use-workload-identity-google#determine_the_workload_identity_pool_for_your_cluster).\n\nAWS IAM identity providers\n--------------------------\n\nAWS IAM supports\n[identity federation using OIDC](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html).\nTo access AWS using a workload's service account identities,\nyou need to\n[create an OIDC provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html)\non AWS IAM. By default, GKE on AWS are not configured with an\nidentity provider for AWS IAM.\n\nAlternatives to workload identity\n---------------------------------\n\nThere are alternative methods to access services from GKE on AWS.\nWe don't recommended the following methods due to complications.\n\n1. Export credentials and store them as Kubernetes Secrets. In this case,\n you must rotate stored credentials manually in both AWS IAM and\n in your cluster. Additionally, if an attacker steals credentials, they can\n exploit them.\n\n2. Attach credentials to the node pools's underlying instances. In this case,\n all workloads running on the same node share the credentials,\n which can result in a greater set of permissions than workloads might\n need. To block access to an instance's permissions, GKE clusters\n blocks access from a Pod to the instance metadata service.\n\nWhat's next\n-----------\n\n- [Using workload identity with Google Cloud services](/kubernetes-engine/multi-cloud/docs/aws/how-to/use-workload-identity-google)\n- [Using workload identity with AWS](/kubernetes-engine/multi-cloud/docs/aws/how-to/use-workload-identity-aws)\n- Learn more about [Workload identity federation](/iam/docs/workload-identity-federation#pools)"]]
