Cette documentation concerne la version la plus récente de GKE sur Azure, publiée en novembre 2021. Consultez les notes de version pour plus d'informations.
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Présentation de Workload Identity
Workload Identity vous permet d'attribuer des identités et une autorisation distinctes et précises pour chaque application du cluster. Workload Identity est la solution recommandée pour que les applications exécutées dans GKE sur Azure puissent accéder aux services Azure et Google Cloud.
Workload Identity est activé pour tous les clusters GKE.
Comptes de service Kubernetes
Workload Identity met en œuvre la fédération d'identité, qui consiste à déléguer l'approbation ou les rôles à un fournisseur externe. Chaque cluster dispose d'un fournisseur OpenID Connect (OIDC) intégré. Lorsqu'un pod s'exécute dans le cluster, il utilise un compte de service Kubernetes.
Le pod peut être configuré pour obtenir un jeton avec des identifiants éphémères pour son compte de service Kubernetes à l'aide d'un volume de jetons de compte de service lié.
Fournisseurs OpenID Connect
Chaque cluster peut agir en tant que fournisseur OpenID Connect (OIDC). Ce fournisseur vous permet de fournir les identifiants du compte de service Kubernetes aux services compatibles avec la fédération d'identité à l'aide d'OIDC.
L'URI d'émetteur de ce fournisseur sert également de point de terminaison de découverte OIDC. Les services peuvent utiliser ce point de terminaison de découverte pour obtenir le jeu de clés Web JSON (JWKS, JSON Web Key Set), qui fournit des informations sur les clés publiques leur permettant de vérifier les identifiants du compte de service Kubernetes.
Pools d'identités et fournisseurs Google Cloud IAM
Google Cloud IAM est compatible avec la fédération d'identité à l'aide d'OIDC.
Tous les clusters GKE sont configurés en tant que fournisseurs d'identité dans le pool d'identités de charge de travail PROJECT_ID.svc.id.goog.
Il existe d'autres méthodes pour accéder aux services depuis GKE sur Azure.
Nous vous déconseillons d'utiliser les méthodes suivantes en raison de difficultés.
Exportez vos identifiants et stockez-les en tant que secrets Kubernetes. Dans ce cas, vous devez alterner les identifiants stockés manuellement dans Azure IAM et dans votre cluster. De plus, si un pirate informatique vole des identifiants, il peut les exploiter.
Associez les identifiants aux instances de calcul sous-jacentes des pools de nœuds. Dans ce cas, toutes les charges de travail exécutées sur le même nœud partagent les identifiants, ce qui peut entraîner un ensemble d'autorisations plus important que nécessaire pour les charges de travail. Pour bloquer l'accès aux autorisations d'une instance, les clusters GKE bloquent l'accès d'un pod au service de métadonnées d'instance.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/06/29 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2024/06/29 (UTC)."],[],[],null,["# Workload identity overview\n==========================\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 Azure to access\nAzure 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/azure/how-to/use-workload-identity-google#determine_the_workload_identity_pool_for_your_cluster).\n\nAlternatives to workload identity\n---------------------------------\n\nThere are alternative methods to access services from GKE on Azure.\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 Azure 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/azure/how-to/use-workload-identity-google)\n- Learn more about [Workload identity federation](/iam/docs/workload-identity-federation#pools)"]]
