À propos de l'identité de l'agent pour GKE

Les charges de travail des agents nécessitent souvent des mesures de protection, un contrôle des accès et des workflows d'authentification différents de ceux des autres types de charges de travail. Vous pouvez utiliser l'identité de l'agent pour attribuer à chaque agent une identité attestée, éphémère et propre à chaque pod. Cette identité vous aide à identifier les charges de travail de l'agent, ainsi qu'à suivre et gérer ce que ces charges de travail font sur Google Cloud. Ce document décrit le fonctionnement de l'identité de l'agent dans Google Kubernetes Engine (GKE), y compris l'intégration à d'autres produitsGoogle Cloud , les types d'authentification que vos agents peuvent utiliser et la manière de régir vos charges de travail à l'aide de ces identités.

Ce document est destiné aux administrateurs de plate-forme et aux ingénieurs en sécurité qui souhaitent améliorer la sécurité des agents exécutés sur les clusters GKE tout en intégrant les agents aux produits et services Google Cloud .

Vous devez déjà maîtriser les thèmes suivants :

Qu'est-ce qu'Agent Identity ?

Google Cloud fournit différents types d'identités pour vos charges de travail, chacun étant destiné à un ensemble spécifique de cas d'utilisation et de types de charges de travail. L'identité d'agent est un type d'identité conçu pour les charges de travail des agents d'IA. Un agent qui utilise Agent Identity obtient une identité unique basée sur la norme SPIFFE. Cette identité est liée au cycle de vie de l'agent, identifie la charge de travail comme un agent et est reconnue par les différents services de la plate-forme Gemini Enterprise Agent, tels qu'Agent Registry et Agent Gateway. Vous pouvez suivre et gérer une charge de travail qui possède une identité d'agent dans tous les services auxquels elle accède, quel que soit l'endroit où elle s'exécute. Une charge de travail qui utilise l'identité de l'agent peut s'authentifier auprès des serveurs MCP, des ressources à l'intérieur et à l'extérieur de Google Cloud, d'autres agents et des points de terminaison en utilisant sa propre identité ou au nom d'un utilisateur final. Pour en savoir plus sur l'identité de l'agent, consultez la présentation de l'identité de l'agent.

Vous pouvez utiliser l'identité de l'agent pour améliorer la sécurité et la gouvernance des agents d'IA que vous déployez dans les clusters GKE, et pour activer des workflows spécifiques pour vos agents, tels que les suivants :

  • Intégrez des agents sur GKE à des produits tels qu'Agent Registry et Agent Gateway.
  • Gérez les rôles pour les charges de travail de l'agent dans les projets, les dossiers ou les organisations dans les stratégies Identity and Access Management (IAM).
  • Réduisez l'impact des agents compromis sur les nœuds et les autres pods du cluster.
  • Configurez différents workflows d'authentification, tels que les agents agissant au nom des utilisateurs finaux, à l'aide du gestionnaire d'authentification des identités d'agent.

Comparaison avec la fédération d'identité de charge de travail pour GKE

L'identité de l'agent et la fédération d'identité de charge de travail pour GKE permettent toutes deux d'attribuer des identités aux charges de travail. L'identité de l'agent est conçue pour le modèle de menace et les exigences spécifiques qui s'appliquent aux agents d'IA, ce qui entraîne diverses différences fonctionnelles. Le tableau suivant compare ces différences de manière générale :

Agent Identity Workload Identity Federation for GKE
Les jetons d'accès à l'identité de l'agent peuvent être liés par cryptographie à des certificats X.509 par pod. Un jeton d'accès lié nécessite une connexion mTLS et ne fonctionne pas lorsqu'il est utilisé en dehors du pod d'origine. Les jetons d'accès fédérés ne sont pas liés de manière cryptographique aux identités de pod, fonctionnent sur des connexions non mTLS et peuvent être utilisés en dehors du pod d'origine.
S'intègre au gestionnaire d'authentification de l'identité de l'agent pour prendre en charge les workflows OAuth et utiliser des identifiants tiers sans gestion manuelle des identifiants. Nécessite l'implémentation manuelle des workflows OAuth et la gestion des identifiants tiers lors de l'authentification auprès d'outils et de services externes.
Fonctionne bien pour les charges de travail autonomes telles que les agents d'IA. Fonctionne bien pour les microservices déterministes tels que les serveurs Web, les API et les jobs par lot.
Nécessite la version 1.37.0-gke.3503000 ou ultérieure de GKE. Disponible dans toutes les versions de GKE.
Les jetons d'accès à l'identité de l'agent lié utilisent toujours le niveau d'accès https://www.googleapis.com/auth/cloud-platform. Les niveaux personnalisés ne sont pas acceptés. Les jetons d'accès fédérés sont compatibles avec les niveaux d'accès personnalisés.
Les applications peuvent obtenir des jetons d'identité d'agent pour s'authentifier directement auprès d'autres charges de travail ou services en aval. Les applications ne peuvent pas obtenir de jetons d'identité, sauf si le compte de service Kubernetes est configuré pour emprunter l'identité d'un compte de service IAM.

Intégration à Agent Platform

Gemini Enterprise Agent Platform inclut plusieurs produits et services conçus pour créer, gérer et exploiter des agents à grande échelle. Si vous exécutez des charges de travail d'agent sur GKE, vous pouvez utiliser les produits Agent Platform en attribuant des identités d'agent aux charges de travail et en enregistrant les charges de travail en tant qu'agents dans Agent Registry. Pour intégrer et utiliser les services Agent Platform avec vos agents GKE, vos opérateurs d'application ajoutent des annotations et des libellés aux spécifications Kubernetes des charges de travail des agents. À part vérifier que Workload Identity Federation pour GKE est activé, vous n'avez pas besoin de modifier la configuration de votre cluster ni de votre pool de nœuds. Vous pouvez ensuite gérer et contrôler vos agents GKE de la même manière que vous le feriez pour un agent qui s'exécute sur Agent Runtime ou Cloud Run.

L'enregistrement dans le registre d'agents permet également d'éviter d'éventuelles interruptions lorsque vous déplacez des projets entre des organisations. Lors du déplacement d'un projet, le registre d'agents vérifie si des agents utilisent une identité basée sur le domaine de confiance au niveau de l'organisation, qui changerait après le déplacement. Si une identité d'agent au niveau de l'organisation est utilisée, le transfert du projet est bloqué. Cette vérification n'est effectuée que pour les déploiements que vous enregistrez dans Agent Registry. La vérification n'a pas lieu avec d'autres contrôleurs de charge de travail ni avec les pods statiques.

Fonctionnement dans GKE

Dans GKE, Agent Identity utilise des concepts tels que le serveur de métadonnées GKE et les pools d'identité, de la même manière que Workload Identity Federation for GKE. Pour utiliser l'identité de l'agent, vous devez également activer Workload Identity Federation for GKE dans le cluster. Google Cloud crée automatiquement un pool d'identités d'agent au niveau du projet ou de l'organisation. Le pool d'identités de l'agent est un domaine de confiance SPIFFE et constitue la racine de confiance pour les identités et les identifiants de l'agent. Les développeurs d'applications peuvent demander une identité d'agent pour leur agent en ajoutant des annotations et des libellés à la spécification de leur pod. Lorsque la charge de travail est déployée sur un cluster, GKE lui attribue les identifiants suivants :

  • Une identité SPIFFE qui identifie la charge de travail. Tous les pods d'une charge de travail gérée, telle qu'un déploiement, partagent l'ID SPIFFE de cette charge de travail. L'ID SPIFFE identifie l'agent dans les services Google Cloud . Vous pouvez suivre toutes les actions effectuées par les pods, que ce soit en tant qu'agent ou au nom d'un utilisateur final, à l'aide de l'ID SPIFFE. L'ID SPIFFE utilise la syntaxe suivante :

    spiffe://TRUST_DOMAIN/resources/container/projects/PROJECT_NUMBER/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/ns/NAMESPACE/sa/SERVICEACCOUNT_NAME

    Cette chaîne d'ID présente les attributs suivants :

    • TRUST_DOMAIN : domaine de confiance SPIFFE, qui possède l'une des valeurs suivantes, selon que le projet contenant le cluster se trouve ou non dans une organisation :
      • Projets appartenant à une organisation : agents.global.org-ORGANIZATION_ID.system.id.goog, où ORGANIZATION_ID est l'ID de l'organisation.
      • Projets qui ne font pas partie d'une organisation : agents.global.proj-PROJECT_NUMBER.system.id.goog, où PROJECT_NUMBER correspond au numéro de projet du projet de cluster.
    • PROJECT_NUMBER : numéro du projet de cluster.
    • CONTROL_PLANE_LOCATION : région ou zone dans laquelle se trouve le plan de contrôle du cluster.
    • CLUSTER_NAME : nom du cluster dans lequel se trouve le pod.
    • NAMESPACE : nom de l'espace de noms Kubernetes dans lequel se trouve le pod.
    • SERVICEACCOUNT_NAME : nom du compte de service Kubernetes attribué au pod.

  • Un bundle d'identifiants d'identité d'agent (x509.credential-bundle.private-key.pem) monté en tant que volume dans chaque pod et pouvant être utilisé pour l'authentification mTLS auprès des API Google Cloud . Ce fichier inclut les identifiants suivants :

    • Chaîne de certificats X.509 incluant l'ID SPIFFE pour la charge de travail de l'agent en tant que paramètre autre nom de l'objet (SAN) et expirant dans 24 heures. La chaîne de certificats permet d'obtenir des jetons d'accès liés et des jetons d'identité pour l'authentification auprès d'autres services.
    • Clé privée que le processus kubelet crée automatiquement pour chaque pod. La clé lie de manière cryptographique le certificat X.509 d'un pod au pod. Cette clé prouve que le pod qui a envoyé une requête est propriétaire du certificat X.509 utilisé pour établir la connexion TLS.

  • Un bundle de confiance d'autorité de certification racine (TRUST_DOMAIN.spiffe-trust-bundle.pem) monté en tant que volume dans chaque pod et pouvant être utilisé pour configurer l'authentification mTLS entre les agents qui utilisent le même domaine de confiance. Lors d'une négociation mTLS, un agent utilise le groupe d'approbations de l'autorité de certification racine pour valider la chaîne de certificats présentée par un agent pair.

Configuration au niveau de la charge de travail

Pour attribuer une identité d'agent et des identifiants par pod à une charge de travail, GKE recherche les annotations suivantes dans la spécification du pod :

  • iam.gke.io/identity: "spiffe://TRUST_DOMAIN/*" : GKE utilise cette annotation pour attribuer aux pods un ID SPIFFE provenant du domaine de confiance correspondant.

  • iam.gke.io/inject-podcertificates: "true" : GKE utilise cette annotation pour ajouter le bundle d'identifiants d'identité de l'agent et le bundle de confiance du cluster à chaque pod de la charge de travail. Si cette annotation est omise, vous ne pouvez pas obtenir de jetons d'accès liés à des pods spécifiques. Les identifiants injectés sont utilisés pour l'authentification mTLS de vos pods vers les APIGoogle Cloud ou les agents pairs.

De plus, Agent Registry utilise le libellé et l'annotation suivants pour enregistrer automatiquement vos agents GKE :

  • Libellé registry.gke.io/functional-type: "AGENT" : identifie la charge de travail comme un agent d'IA et ajoute l'agent à Agent Registry. Ce libellé n'est compatible qu'avec les déploiements et doit être spécifié dans le champ metadata.labels du fichier manifeste de déploiement.
  • L'annotation iam.gke.io/spiffe-identity-type: "agent-identity" indique que l'agent utilise Agent Identity. Cette annotation est spécifiée dans la spécification du pod. Si le libellé registry.gke.io/functional-type: "AGENT" est spécifié pour un déploiement, cette annotation est requise dans la spécification du pod.

Pour intégrer vos agents GKE à Agent Platform, enregistrez vos charges de travail auprès d'Agent Registry en plus d'utiliser l'identité de l'agent. Envisagez d'appliquer l'enregistrement des charges de travail de l'agent ou d'automatiser l'enregistrement dans votre pipeline de déploiement.

Jetons d'accès pour les agents

Dans GKE, chaque pod qui utilise l'identité de l'agent reçoit un ensemble d'identifiants unique contenant le certificat X.509 et la clé privée du pod, qui ne quitte pas le pod. Pour accéder à des API Google Cloud ou à des services externes, un pod d'agent dans un cluster GKE demande un jeton d'accès à l'identité de l'agent au serveur de métadonnées GKE qui s'exécute sur chaque nœud. Le pod utilise le jeton d'accès à l'identité de l'agent pour s'authentifier en tant qu'identité de l'agent.

Le jeton d'accès peut être lié ou non lié, comme suit :

  • Jeton d'accès lié : lié de manière cryptographique au certificat X.509 du pod. Il ne peut être utilisé que pour les connexions mTLS authentifiées à l'aide de ce certificat X.509. Toute demande de jeton d'accès incluant le certificat X.509 dans la charge utile génère un jeton lié.
  • Jeton d'accès non lié : il n'est pas lié de manière cryptographique à un pod spécifique et peut être utilisé sur des connexions non mTLS. Les jetons d'accès non liés sont plus vulnérables aux attaques par relecture de jetons, car un jeton divulgué peut être utilisé par un autre pod.

Les agents utilisent les jetons d'accès liés ou non liés pour authentifier leurs requêtes auprès des APIGoogle Cloud . Les administrateurs d'identité peuvent contrôler l'accès d'un agent en spécifiant l'identifiant principal du jeton d'accès à l'identité de cet agent dans les stratégies IAM, comme décrit dans Contrôler l'accès aux ressources Google Cloud pour les agents.

Si les pods comportent l'annotation iam.gke.io/inject-podcertificates: "true", les bibliothèques clientes Cloud et les bibliothèques d'authentification Google utilisent les identifiants par défaut de l'application (ADC) pour obtenir automatiquement un jeton d'accès à l'identité de l'agent lié pour les pods. Ce processus automatique peut ne pas se produire dans toutes les bibliothèques ni dans tous les langages de programmation. Pour demander des jetons d'accès non associés, les développeurs utilisent l'une des méthodes suivantes :

  • Spécifiez l'annotation iam.gke.io/inject-podcertificates: "true" et définissez la variable d'environnement GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN sur la valeur false dans la spécification du pod. GKE ajoute le bundle d'identifiants X.509 au pod, mais la variable d'environnement entraîne l'obtention de jetons d'accès non liés par ADC.

    Cette méthode permet aux pods de continuer à établir des connexions mTLS avec d'autres charges de travail en utilisant les certificats, tout en utilisant des jetons d'accès non liés pour accéder aux API Google Cloud .

  • Ne spécifiez pas l'annotation iam.gke.io/inject-podcertificates: "true" dans la spécification du pod. GKE n'ajoute pas le bundle d'identifiants X.509 au pod. ADC obtient donc des jetons d'accès non liés pour les pods.

  • Envoyez une requête HTTP GET directe au point de terminaison du jeton du serveur de métadonnées GKE, qui renvoie un jeton d'accès non lié.

Workflows d'authentification pour les agents

Contrairement aux charges de travail non liées à un agent, les agents peuvent avoir besoin de s'authentifier auprès des services au nom d'un utilisateur final ou en tant qu'identité propre de l'agent, selon la tâche que l'agent tente d'effectuer. L'identité de l'agent permet l'authentification aux types de ressources suivants à l'aide de divers identifiants et modèles d'authentification :

  • APIGoogle Cloud
  • Outils et services externes
  • Authentification d'agent à agent

S'authentifier auprès des API Google Cloud

Un agent peut utiliser sa propre identité pour s'authentifier auprès des API Google Cloud , comme BigQuery ou Agent Platform. Pour s'authentifier, le pod obtient un jeton d'accès à l'identité de l'agent à partir du serveur de métadonnées GKE sur le nœud. Ce jeton d'accès peut éventuellement être lié au certificat X.509 du pod, ce qui signifie qu'il ne peut être utilisé que sur une connexion mTLS authentifiée à l'aide du certificat X.509.

Si votre application utilise la version 2.61.0 ou ultérieure de la bibliothèque d'authentification Python google-auth, les Identifiants par défaut de l'application (ADC) demandent automatiquement des jetons d'accès liés pour les pods qui disposent du bundle d'identifiants d'identité de l'agent. Si vous utilisez les bibliothèques clientes Cloud pour Python, assurez-vous d'utiliser une version qui inclut la version 2.61.0 ou ultérieure de la bibliothèque google-auth. Pour les autres langages de programmation ou pour les versions de la bibliothèque Python google-auth antérieures à 2.61.0, demandez plutôt des jetons d'accès non liés.

Si vous obtenez un jeton d'accès lié, vous devez utiliser le certificat X.509 du pod pour établir une connexion mTLS avec le point de terminaison mTLS de l'API de destination. Si vous obtenez un jeton d'accès non lié, vous pouvez l'utiliser dans les requêtes adressées au point de terminaison non mTLS de cette API.

Pour configurer le code de votre application afin d'obtenir des jetons d'accès liés ou non liés à l'aide de ces méthodes, consultez S'authentifier à l'aide d'une identité d'agent dans GKE.

Si vous êtes administrateur de plate-forme ou administrateur de sécurité, vous n'avez pas besoin de configurer d'authentification supplémentaire pour les agents qui s'authentifient auprès des APIGoogle Cloud . Vous pouvez contrôler l'accès aux ressources à l'aide des stratégies IAM, comme décrit dans Contrôler l'accès aux ressources Google Cloud pour les agents.

Authentification de l'agent auprès de services externes

Les agents ont souvent besoin d'accéder à des outils et services externes à l'aide d'identifiants spécifiques, tels que des clés API ou des jetons OAuth. L'agent peut avoir besoin de s'authentifier en tant qu'identité propre ou au nom d'un utilisateur final. Vous pouvez fournir des identifiants spécifiques aux agents à l'aide du gestionnaire d'authentification de l'identité de l'agent (aperçu). Le gestionnaire d'authentification centralise l'acquisition d'identifiants et la configuration du workflow d'authentification pour les agents que vous exécutez sur Google Cloud.

Dans le gestionnaire d'authentification, vous configurez des fournisseurs d'authentification pour gérer des workflows d'authentification spécifiques. Lorsqu'un agent dans GKE doit s'authentifier à l'aide d'identifiants spécifiques, le pod utilise son jeton d'accès à l'identité de l'agent pour s'authentifier auprès du gestionnaire d'authentification. Le fournisseur d'authentification gère ensuite toutes les étapes d'authentification supplémentaires et renvoie les identifiants demandés au pod. Le gestionnaire d'authentification échange les identifiants externes contre des jetons d'accès de courte durée, de sorte que les jetons d'actualisation et les codes secrets de l'API de longue durée ne sont pas stockés dans le conteneur de l'agent.

Vous pouvez utiliser le gestionnaire d'authentification pour les cas d'utilisation suivants, qui impliquent chacun une configuration spécifique dans le gestionnaire d'authentification et dans le code de l'application :

  • Accéder à des services externes au nom d'un utilisateur final.
  • Accéder à des services externes avec sa propre identité.
  • Accédez aux API à l'aide d'une clé API.

Vous pouvez surveiller et révoquer les identifiants créés par le gestionnaire d'authentification. Vous pouvez également suivre les identifiants utilisés par des agents spécifiques, car l'agent s'authentifie auprès du gestionnaire d'authentification à l'aide de son jeton d'accès à l'identité de l'agent. Les sections suivantes décrivent les cas d'utilisation du gestionnaire d'authentification et les modèles d'authentification correspondants. Selon le modèle d'authentification que vous utilisez, vous et vos développeurs d'applications devez apporter des modifications spécifiques au code de l'agent et aux applications côté client.

Accès à des services externes au nom d'un utilisateur final

Un utilisateur final peut demander à un agent d'effectuer certaines actions en son nom, comme écrire des messages dans un canal Slack ou ouvrir une demande d'extraction d'extraction dans un dépôt GitHub. Dans ces scénarios, l'utilisateur délègue son autorité à l'agent en consentant explicitement à ce que l'agent agisse en son nom. Pour configurer le consentement utilisateur et la récupération des identifiants, vous utilisez OAuth en trois étapes, qui comprend les étapes suivantes :

  1. Le fournisseur d'authentification redirige l'utilisateur pour qu'il s'authentifie auprès du service externe.
  2. L'utilisateur se connecte et approuve l'accès dont l'agent a besoin.
  3. Le service externe renvoie un identifiant au fournisseur d'authentification.

Pour configurer OAuth à trois niveaux pour un agent qui s'exécute sur GKE, l'administrateur de la plate-forme et le développeur d'applications doivent procéder comme suit :

  1. L'administrateur de la plate-forme configure le fournisseur d'authentification :
    1. Créez un fournisseur d'authentification OAuth en trois étapes dans le gestionnaire d'authentification.
    2. Configurez le fournisseur d'authentification pour qu'il redirige vers le serveur d'autorisation tiers.
    3. Configurez le service tiers pour qu'il envoie le jeton d'accès utilisateur au fournisseur d'authentification.
    4. Autorisez l'agent à accéder au fournisseur d'authentification.
  2. Le développeur d'applications modifie l'application :
    1. Modifiez le code de l'agent pour vous authentifier à l'aide du fournisseur d'authentification.
    2. Modifiez le code de l'application côté client pour gérer la connexion, la redirection et la reprise de la conversation par l'utilisateur.

Pour savoir comment configurer le fournisseur d'authentification et modifier vos applications côté agent et côté client, consultez S'authentifier à l'aide d'OAuth en trois étapes avec le gestionnaire d'authentification.

Accès à des services externes en tant qu'identité de l'agent

Un agent peut avoir besoin d'accéder à des services externes tels que ServiceNow ou Salesforce en utilisant sa propre identité. Par exemple, un agent de gestion des stocks peut surveiller les données de vente et commander des stocks pour éviter les problèmes de stock lors des pics de vente. Dans ces scénarios, vous utilisez OAuth à deux identifiants, qui comprend les étapes suivantes :

  1. Le gestionnaire d'authentification demande un jeton d'accès au service externe.
  2. Le service externe valide la requête et renvoie le jeton d'accès au gestionnaire d'authentification.

Pour configurer OAuth à deux étapes pour un agent qui s'exécute sur GKE, procédez comme suit :

  1. L'administrateur de la plate-forme configure le fournisseur d'authentification :
    1. Obtenez un ID client OAuth, un code secret du client et un point de terminaison de jeton auprès du service externe.
    2. Créez un fournisseur d'authentification OAuth en deux étapes dans le gestionnaire d'authentification, qui contient les informations OAuth du service externe.
    3. Autorisez l'agent à accéder au fournisseur d'authentification.
  2. Le développeur de l'application modifie le code de l'agent pour s'authentifier à l'aide du fournisseur d'authentification.

Pour savoir comment configurer le fournisseur d'authentification et modifier le code de votre agent, consultez S'authentifier à l'aide d'OAuth à deux facteurs avec le gestionnaire d'authentification.

Accéder aux API à l'aide d'une clé API

Vous pouvez stocker des clés API dans le gestionnaire d'authentification pour que les agents puissent s'authentifier auprès des API externes. Bien que vous puissiez stocker des clés API dans d'autres coffres-forts tels que Secret Manager, la méthode du gestionnaire d'authentification vous permet de suivre et de gérer l'accès des agents aux clés API de manière centralisée. Pour stocker et utiliser des clés API dans le gestionnaire d'authentification, procédez comme suit :

  1. L'administrateur de la plate-forme configure le fournisseur d'authentification :
    1. Créez un fournisseur d'authentification par clé API dans le gestionnaire d'authentification.
    2. Générez et stockez la clé API dans le fournisseur d'authentification.
    3. Autorisez l'agent à accéder au fournisseur d'authentification.
  2. Modifiez le code de l'agent pour vous authentifier à l'aide du fournisseur d'authentification.

Pour en savoir plus, consultez S'authentifier à l'aide d'une clé API avec le gestionnaire d'authentification.

Authentification d'agent à agent

Cette section décrit un workflow d'authentification avancée. Vous devez déjà connaître les thèmes suivants :

  • Jetons Web JSON (JWT) : les jetons d'identité de l'agent sont des JWT signés.
  • En-têtes JOSE (JSON Object Signing and Encryption) : les jetons d'identité comportent un en-tête JOSE qui décrit l'algorithme et la clé de signature du jeton d'identité.
  • Clés Web JSON (JWK) : les JWK sont utilisées pour signer les jetons d'identité. Les JWKS publics d'un pool d'identités d'agent sont publiés en tant que jeu de clés Web JSON (JWKS). Vous utilisez ces clés publiques pour valider les jetons d'identité entrants provenant d'autres agents.

Dans les architectures multi-agents, les agents collaborent fréquemment en appelant directement des agents pairs ou des services en aval. Vous pouvez établir directement la communication entre les charges de travail de l'agent à l'aide d'un jeton d'identité d'identité de l'agent, qui est un JWT signé que vous pouvez obtenir à partir du serveur de métadonnées GKE. Pour authentifier une connexion entre les services d'agent, les développeurs d'applications procèdent comme suit :

  1. Obtenez un jeton d'identité de l'agent à partir du serveur de métadonnées GKE pour l'agent appelant. Ce jeton d'identité doit définir la revendication aud sur le point de terminaison de l'agent destinataire.
  2. Incluez le jeton d'ID dans l'en-tête de requête Authorization: Bearer de la requête HTTP.
  3. Dans l'agent de réception, validez le jeton d'identité entrant à l'aide des JWK publics pour le pool d'identités de l'agent et des différents paramètres d'en-tête et de corps du jeton d'identité.

Pour savoir comment demander, utiliser et valider des jetons d'identité dans le code de votre application, consultez S'authentifier auprès d'autres agents.

L'authentification d'agent à agent ne nécessite aucune Google Cloudconfiguration supplémentaire de la part d'un administrateur de plate-forme, car ce workflow contourne les vérifications d'autorisation IAM. Au lieu de cela, les agents communiquent directement entre eux et autorisent les actions en fonction de leur identité.

Contrôler l'accès aux ressources Google Cloud pour les agents

Les administrateurs de sécurité peuvent contrôler les ressources auxquelles un agent peut accéder à l'aide de stratégies IAM qui font référence à l'identifiant principal de l'agent. Pour contrôler l'accès aux ressources d'un agent qui s'exécute sur GKE et qui possède une identité d'agent, vous devez inclure l'un des identifiants de compte principal suivants dans votre stratégie IAM :

  • Tous les agents d'un domaine de confiance spécifique :

    principalSet://TRUST_DOMAIN/*

    Dans cet identifiant, TRUST_DOMAIN est le domaine de confiance pour votre hiérarchie de ressources, qui dépend de l'emplacement de l'agent (dans un projet d'une organisation ou non) :

    • Projets appartenant à une organisation : agents.global.org-ORGANIZATION_ID.system.id.goog, où ORGANIZATION_ID est l'ID de l'organisation.
    • Projets qui ne font pas partie d'une organisation : agents.global.proj-PROJECT_NUMBER.system.id.goog, où PROJECT_NUMBER correspond au numéro du projet de cluster.

  • Un seul agent dans un domaine de confiance :

    principal://TRUST_DOMAIN/resources/container/projects/PROJECT_NUMBER/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME

    Dans cet identifiant, les paramètres suivants identifient l'agent spécifique :

    • PROJECT_NUMBER : numéro du projet du cluster.
    • CONTROL_PLANE_LOCATION : région ou zone du plan de contrôle du cluster.
    • CLUSTER_NAME : nom du cluster dans lequel se trouve l'agent.
    • NAMESPACE_NAME : nom de l'espace de noms Kubernetes dans lequel se trouve l'agent.
    • SERVICEACCOUNT_NAME : nom du compte de service Kubernetes utilisé par la charge de travail de l'agent.

Pour savoir comment trouver les identifiants principaux des agents GKE et gérer les accès, consultez Gérer l'accès aux API Google Cloud pour les agents.

L'identité de l'agent est compatible avec tous les types de stratégies IAM, comme les stratégies d'autorisation, les stratégies de refus et les stratégies de limite d'accès des comptes principaux (PAB). Pour gérer l'accès d'un agent dans un cluster GKE qui utilise l'identité de l'agent, vous devez inclure l'identifiant principal de l'agent dans le type de règle correspondant. Pour savoir comment configurer chaque type de stratégie IAM, consultez les rubriques suivantes :

Afficher et gérer les agents dans Google Cloud

Si les développeurs d'applications enregistrent leurs agents dans le registre d'agents, vous pouvez afficher les agents GKE à côté des autres agents que vous exécutez dans Google Cloud. Le registre d'agents affiche l'identité SPIFFE de l'agent, l'endroit où il s'exécute et toute information supplémentaire le concernant. Toutes les requêtes API authentifiées à l'aide d'Agent Identity génèrent des journaux d'audit Agent Registry. Selon le workflow d'authentification utilisé par l'agent, Cloud Audit Logs fournit les informations suivantes :

  • Authentification à l'aide de la propre identité de l'agent : les journaux d'audit générés incluent l'identifiant principal de l'agent, que vous pouvez utiliser pour trouver le cluster, l'espace de noms et le compte de service de l'agent.
  • Opérations déléguées au nom des utilisateurs finaux : les journaux d'audit générés incluent des informations sur l'utilisateur final qui a autorisé l'action et l'ID SPIFFE de l'agent qui a exécuté l'appel. Cette association d'identité dans les journaux d'audit vous aide à valider que l'utilisateur final a autorisé des actions spécifiques.

En plus de Cloud Audit Logs, les développeurs d'applications peuvent configurer leurs charges de travail d'agent pour émettre des traces, des journaux et des métriques qui deviennent visibles dans Google Cloud Observability. Pour savoir comment configurer les charges de travail, consultez les documents suivants :

Améliorer la sécurité des agents GKE

Les administrateurs de la sécurité peuvent gérer les mesures de sécurité spécifiques aux agents séparément des contraintes pour les autres types de charges de travail en référençant les identités des agents. Tenez compte des mesures défensives suivantes lorsque vous exécutez des agents :

Limites

  • Vous ne pouvez enregistrer automatiquement que les déploiements dans le registre d'agents. Les autres contrôleurs de charge de travail et les pods statiques ne sont pas compatibles avec l'enregistrement automatique.
  • Les jetons d'accès à l'identité de l'agent lié n'utilisent que le champ d'application OAuth https://www.googleapis.com/auth/cloud-platform. Vous ne pouvez pas spécifier une portée différente pour les jetons d'accès liés.
  • La récupération automatique des jetons d'accès ou d'identité liés n'est compatible qu'avec les applications Python qui utilisent la version 2.61.0 ou ultérieure de la bibliothèque google-auth. Si vous utilisez les bibliothèques clientes Cloud pour Python, vous devez utiliser une version qui inclut la version 2.61.0 ou ultérieure de la bibliothèque google-auth.
  • Il est possible que certaines bibliothèques clientes Cloud ne redirigent pas automatiquement vos requêtes vers les points de terminaison mTLS.
  • Pour l'authentification d'agent à agent, vous ne pouvez utiliser que des jetons d'identité liés pour l'authentification entre agents appartenant au même domaine de confiance pour l'identité des agents.

Étapes suivantes