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.

Pour obtenir le nom de votre pool d'identités de charge de travail et de vos fournisseurs, consultez la page Utiliser Workload Identity avec Google Cloud.

Alternatives aux identités de charge de travail

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.

  1. 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.

  2. 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.

Étapes suivantes