Utiliser Workload Identity de parc

Les applications doivent souvent s'authentifier (fournir une identité authentifiable) lorsqu'elles se connectent à d'autres services. Par exemple, vos applications doivent s'authentifier pour utiliser les API Google Cloud telles que les API Compute Engine ou AI Platform. Cette page explique comment utiliser Workload Identity de parc, la méthode la plus simple et recommandée pour les charges de travail d'application hébergées dans un parc afin de s'authentifier auprès des API Google Cloud et des services.

Qu'est-ce que Workload Identity de parc ?

Workload Identity de parc étend les fonctionnalités fournies par GKE Workload Identity, qui permet aux charges de travail de votre cluster de s'authentifier auprès de Google sans avoir à télécharger, effectuer une rotation manuelle ni gérer des clés de compte de service Google Cloud. Les charges de travail utilisent à la place des jetons de courte durée générés par le cluster. Tous les clusters sur lesquels GKE Workload Identity est activé utilisent le pool d'identités de la charge de travail de leur projet lors de l'émission d'ID, ce qui permet à Identity and Access Management de faire confiance aux identifiants du compte de service Kubernetes et de les comprendre. Pour en savoir plus sur GKE Workload Identity, consultez la page Utiliser Workload Identity.

Avec les parcs, les clusters enregistrés peuvent bénéficier de l'avantage supplémentaire de l'utilisation de Workload Identity pour parc. Les clusters enregistrés pour lesquels Workload Identity est activé au niveau de leur appartenance au parc peuvent utiliser le pool d'identités de charge de travail du parc, ce qui simplifie la configuration de l'authentification auprès des API Google et d'autres services sur l'ensemble de votre parc et de plusieurs projets. Workload Identity pour parc peut également être utilisé par l'agent Connect sur certains types de clusters pour s'authentifier auprès de Google en cas d'appartenance à un parc. Il est nécessaire d'utiliser certaines fonctionnalités de GKE Enterprise compatibles avec plusieurs projets, telles que Cloud Service Mesh.

Fonctionnement

Les flottes utilisent la fédération d'identité de charge de travail pour fournir à chaque application une identité fédérée distincte qui permet de s'authentifier auprès de Google Cloud et d'autres services que vous développez. Les applications exécutées dans un parc reçoivent une identité de charge de travail fédérée au format suivant :

serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]

Où :

  • FLEET_PROJECT_ID.svc.id.goog est une représentation courte du pool d'identités de charge de travail de votre parc. Il n'existe qu'un seul pool d'identités de charge de travail fixe par parc, et il est créé automatiquement.
  • K8S_NAMESPACE est l'espace de noms Kubernetes dans lequel le compte de service Kubernetes est défini.
  • KSA_NAME est le nom du compte de service Kubernetes associé à l'application.

Toutes les applications hébergées dans un parc partagent le même pool d'identités de charge de travail, fournissant ainsi aux applications une identité fédérée qui permet de ne plus dépendre de l'emplacement où chaque application est hébergée. Cela permet d'accorder à une application d'un parc l'accès à une ressource (telle qu'une API Google Cloud) en une seule fois plutôt que cluster par cluster, même si l'application est déployée sur différents projets Google Cloud ou sur différents clouds. Comme pour les autres fonctionnalités compatibles avec les parcs, cela repose sur le principe d'uniformité du parc, qui consiste à traiter comme une même entité les objets Kubernetes portant le même nom dans différents clusters. Ainsi, si vous avez une application avec un backend déployé sur plusieurs clusters dans le même parc et qui doit s’authentifier auprès d'une API Google, vous pouvez facilement la configurer pour que tous les services de l'espace de noms "backend" puissent accéder à cette API. Pour en savoir plus sur la façon dont les parcs utilisent l'uniformité, y compris l'uniformité d'identité, consultez la section Fonctionnement des parcs.

Les clusters externes à Google Cloud peuvent également utiliser Workload Identity pour parc afin de fournir une identité permettant à l'agent Connect de s'authentifier auprès de Google. Pour en savoir plus sur les types de clusters qui utilisent la fonctionnalité Workload Identity du parc, consultez la section Configuration du cluster ci-dessous.

Avant de commencer

  • Assurez-vous que les outils de ligne de commande suivants sont installés :

    • La dernière version de Google Cloud CLI qui inclut gcloud, l'outil de ligne de commande qui permet d'interagir avec Google Cloud.
    • kubectl

    Si vous utilisez Cloud Shell comme environnement shell pour interagir avec Google Cloud, ces outils sont installés pour vous.

  • Assurez-vous d'avoir initialisé gcloud CLI à utiliser avec votre projet.

Configurer le cluster

Pour que les applications de votre parc puissent recevoir une identité de charge de travail, les clusters sur lesquels elles s'exécutent doivent être enregistrés dans votre parc et correctement configurés pour utiliser l'identité de charge de travail du parc. La marche à suivre dépend du type de cluster. La plupart des clusters GKE en dehors de Google Cloud sont enregistrés automatiquement dans le parc de votre projet lorsque vous les créez. Les clusters GKE sur Google Cloud et les clusters associés doivent être enregistrés manuellement.

Pour en savoir plus sur la configuration des clusters, consultez la documentation de chaque type de cluster.

GKE

  1. Activez GKE Workload Identity sur votre cluster Google Kubernetes Engine si ce n'est pas déjà fait.
  2. Suivez les instructions pour enregistrer le cluster à l'aide de Workload Identity.

Clusters GKE en dehors de Google Cloud

Les clusters sur site sur VMware et sur Bare Metal, ainsi que les clusters GKE multicloud (sur AWS et Azure) sont automatiquement enregistrés dans votre parc de projets au moment de la création du cluster. Tous ces types de clusters activent automatiquement la fonctionnalité Workload Identity du parc lorsqu'ils sont enregistrés.

Clusters associés

Les clusters associés EKS et AKS enregistrés à l'aide de l'API GKE Multi-Cloud sont enregistrés avec la fonctionnalité Workload Identity du parc activée par défaut. Les autres clusters associés peuvent être enregistrés lorsque la charge de travail du parc est activée, s'ils répondent aux conditions préalables. Suivez les instructions correspondant à votre type de cluster de la page Enregistrer un cluster.

Utiliser Workload Identity de parc

Une fois que vous avez enregistré votre cluster, les charges de travail déployées sur le cluster peuvent utiliser les identités de charge de travail du pool d'identités de charge de travail de parc. Cette section explique comment utiliser l'identité de charge de travail pour emprunter l'identité d'un compte de service Google Cloud afin que vos charges de travail puissent accéder aux API Google Cloud. Agir en tant que compte de service est un cas d'utilisation courant pour les identités fédérées, car cela permet à vos charges de travail de s'authentifier auprès d'une API Google Cloud à laquelle le compte de service a accès, ce qui élimine les tâches de maintenance et de sécurité liées à la gestion des clés de compte de service pour chaque charge de travail.

Emprunter l'identité d'un compte de service

Cette section explique comment configurer l'identité de la charge de travail fédérée d'une application pour emprunter l'identité d'un compte de service en fournissant un fichier d'identifiants par défaut de l'application dans un ConfigMap, y compris en créant et en configurant le compte de service avec les autorisations appropriées.

L'exemple utilise les valeurs d'espace réservé suivantes :

  • WORKLOAD_IDENTITY_POOL est le pool d'identités de charge de travail associé à votre parc. Comme indiqué ci-dessus, la valeur de WORKLOAD_IDENTITY_POOL est FLEET_PROJECT_ID.svc.id.goog.
  • IDENTITY_PROVIDER est le nom du fournisseur d'identité associé à votre cluster Kubernetes.
  • K8S_NAMESPACE est l'espace de noms Kubernetes dans lequel le compte de service Kubernetes est défini.
  • KSA_NAME est le nom du compte de service Kubernetes associé à l'application.
  • GSA_NAME est le nom du compte de service Google pour le compte duquel que votre application agira.
  • GSA_PROJECT_ID correspond à l'ID du projet dans lequel le compte de service Google est défini.

Pour configurer l'identité de charge de travail de parc afin qu'elle emprunte l'identité d'un compte de service, procédez comme suit :

  1. Assurez-vous que votre cluster est enregistré dans le parc en suivant les étapes décrites dans la section Configurer le cluster ci-dessus.

  2. Obtenez les valeurs de WORKLOAD_IDENTITY_POOL et IDENTITY_PROVIDER pour votre cluster enregistré en récupérant les informations d'appartenance à un parc du cluster à l'aide de la commande suivante. Remplacez MEMBERSHIP par le nom d'appartenance unique de votre cluster dans le parc :

    gcloud container fleet memberships describe MEMBERSHIP \
  --project=FLEET_PROJECT_ID

    Le résultat de la description de l'appartenance ressemble à ceci (certains champs ont été omis pour plus de clarté) :

    authority:
 identityProvider: IDENTITY_PROVIDER
 workloadIdentityPool: WORKLOAD_IDENTITY_POOL
name: projects/FLEET_PROJECT_ID/locations/global/memberships/MEMBERSHIP

  3. Créez un compte de service Google Cloud dont votre application peut emprunter l'identité lors de l'authentification auprès de Google, si vous n'en possédez pas déjà un :

    gcloud iam service-accounts create GSA_NAME --project=GSA_PROJECT_ID

    Le compte de service n'a pas besoin d'être dans le projet hôte de votre parc. Vous pouvez utiliser n'importe quel compte de service Google Cloud dans votre organisation. Pour en savoir plus sur les comptes de service et leur fonctionnement, consultez la page Comptes de service.

  4. Assurez-vous d'avoir accordé au compte de service toutes les autorisations nécessaires pour accéder aux API Google Cloud en ajoutant les liaisons de stratégie IAM requises. Pour ce faire, vous pouvez utiliser gcloud iam service-accounts add-iam-policy-binding ou une autre méthode si vous le souhaitez. Pour connaître les autorisations requises pour utiliser les API Google Cloud dans la documentation de chaque service, consultez la liste complète des rôles prédéfinis avec les autorisations nécessaires dans la page Comprendre les rôles.

  5. Autorisez l'identité de charge de travail de votre application à emprunter l'identité du compte de service en créant une liaison de stratégie IAM, comme suit. Cette liaison permet à l'identité de charge de travail fédérée de votre application d'agir en tant que compte de service Google Cloud.

    gcloud iam service-accounts add-iam-policy-binding \
  GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com \
  --project=GSA_PROJECT_ID \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:WORKLOAD_IDENTITY_POOL[K8S_NAMESPACE/KSA_NAME]"

    Le champ --member est la représentation IAM de l'identité de charge de travail fédérée de votre application.

  6. Créez un fichier ConfigMap contenant le fichier d'identifiants par défaut de l'application pour votre charge de travail. Ce fichier indique à la bibliothèque cliente compilée dans votre charge de travail comment s'authentifier auprès de Google. Le fichier d'identifiants par défaut de l'application contient les informations pertinentes sur le pool d'identités de charge de travail et le compte de service, ainsi que le chemin d'accès au jeton prévu qui sera installé dans le système de fichiers de votre conteneur à l'étape suivante. GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com est l'adresse e-mail du compte de service dont l'identité doit être empruntée.

    Cette configuration n'accorde pas à elle seule l'accès afin d'emprunter l'identité du compte de service. Si la liaison IAM n'existe pas non plus, le pod ne pourra pas utiliser le compte de service.

    kind: ConfigMap
apiVersion: v1
metadata:
  namespace: K8S_NAMESPACE
  name: my-cloudsdk-config
data:
  config: |
    {
      "type": "external_account",
      "audience": "identitynamespace:WORKLOAD_IDENTITY_POOL:IDENTITY_PROVIDER",
      "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com:generateAccessToken",
      "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
      "token_url": "https://sts.googleapis.com/v1/token",
      "credential_source": {
        "file": "/var/run/secrets/tokens/gcp-ksa/token"
      }
    }

  7. Suivez l'exemple ci-dessous pour configurer votre charge de travail. Notez que le ConfigMap de l'étape précédente est installé dans le système de fichiers du conteneur en tant que google-application-credentials.json, avec le fichier de jeton du compte de service prévu, dans /var/run/secrets/tokens/gcp-ksa. Les jetons prévus sont émis par Kubernetes et représentent l'identité de charge de travail au sein du cluster. Ces jetons sont automatiquement échangés avec Google par les bibliothèques clientes Cloud pour obtenir des jetons capables de s'authentifier auprès des API Google. Le champ audience du jeton prévu doit être défini sur la valeur WORKLOAD_IDENTITY_POOL.

    kind: Namespace
apiVersion: v1
metadata:
  name:  K8S_NAMESPACE
---
kind: ServiceAccount
apiVersion: v1
metadata:
  namespace:  K8S_NAMESPACE
  name: KSA_NAME
automountServiceAccountToken: false
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace:  K8S_NAMESPACE
spec:
  serviceAccountName: KSA_NAME
  containers:
  - name: my-container
    image: my-image
    env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json
    volumeMounts:
    - name: gcp-ksa
      mountPath: /var/run/secrets/tokens/gcp-ksa
      readOnly: true
  volumes:
  - name: gcp-ksa
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          path: token
          audience: WORKLOAD_IDENTITY_POOL
          expirationSeconds: 172800
      - configMap:
          name: my-cloudsdk-config
          optional: false
          items:
            - key: "config"
              path: "google-application-credentials.json"

S'authentifier à partir du code

Les bibliothèques clientes Cloud gèrent automatiquement l'authentification auprès de Google Cloud lorsque vous les utilisez pour accéder aux services Google à partir de votre code. Pour utiliser la configuration présentée ci-dessus dans vos applications, vous devez utiliser les bibliothèques clientes Cloud compatibles avec la fédération d'identité de charge de travail. Vous trouverez ci-dessous les versions minimales requises des bibliothèques clientes Cloud, ainsi que des instructions pour la vérification de votre version actuelle :

C++

La plupart des bibliothèques clientes Google Cloud pour C++ sont compatibles avec la fédération d'identité à l'aide d'un objet ChannelCredentials, créé en appelant grpc::GoogleDefaultCredentials(). Pour initialiser cet identifiant, vous devez créer les bibliothèques clientes avec la version 1.36.0 ou ultérieure de gRPC.

La bibliothèque cliente Cloud Storage pour C++ utilise l'API REST et non gRPC. Elle n'est donc pas compatible avec la fédération d'identités.

Go

Les bibliothèques clientes pour Go sont compatibles avec la fédération d'identité si elles utilisent la version 0.0.0-20210218202405-ba52d332ba99 ou une version ultérieure du module golang.org/x/oauth2.

Pour vérifier quelle version de ce module est utilisée par votre bibliothèque cliente, exécutez les commandes suivantes :

cd $GOPATH/src/cloud.google.com/go
go list -m golang.org/x/oauth2

Java

Les bibliothèques clientes pour Java sont compatibles avec la fédération d'identité si elles utilisent la version 0.24.0 ou une version ultérieure de l'artefact com.google.auth:google-auth-library-oauth2-http.

Pour vérifier la version de cet artefact utilisée par votre bibliothèque cliente, exécutez la commande Maven suivante dans le répertoire de votre application :

mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http

Node.js

Les bibliothèques clientes pour Node.js sont compatibles avec la fédération d'identité si elles utilisent la version 7.0.2 ou ultérieure du package google-auth-library.

Pour vérifier la version de ce package utilisée par votre bibliothèque cliente, exécutez la commande suivante dans le répertoire de votre application :

npm list google-auth-library

Lorsque vous créez un objet GoogleAuth, vous pouvez spécifier un ID de projet ou autoriser GoogleAuth à le trouver automatiquement. Pour trouver automatiquement l'ID du projet, le compte de service dans le fichier de configuration doit disposer du rôle de visiteur (roles/browser) ou d'un rôle avec des autorisations équivalentes sur votre projet. Pour en savoir plus, consultez la section README du package google-auth-library.

Python

Les bibliothèques clientes pour Python sont compatibles avec la fédération d'identité si elles utilisent la version 1.27.0 ou ultérieure du package google-auth.

Pour vérifier la version de ce package utilisée par votre bibliothèque cliente, exécutez la commande suivante dans l'environnement dans lequel le package est installé :

pip show google-auth

Pour spécifier un ID de projet pour le client d'authentification, vous pouvez définir la variable d'environnement GOOGLE_CLOUD_PROJECT ou autoriser le client à trouver automatiquement l'ID du projet. Pour trouver automatiquement l'ID du projet, le compte de service dans le fichier de configuration doit disposer du rôle de visiteur (roles/browser) ou d'un rôle avec des autorisations équivalentes sur votre projet. Pour en savoir plus, consultez le guide de l'utilisateur du package google-auth.