Architecture de délégation d'identité

Pour appliquer des limites de confiance entre les utilisateurs humains, les charges de travail autonomes et les outils externes sans recourir à l'emprunt d'identité d'un compte de service, l'identité d'agent utilise un framework de délégation à trois identités. Ce framework sépare et coordonne trois contextes d'identité distincts dans votre environnement :

  • Identité de l'utilisateur : identité de l'utilisateur final à l'origine de la requête, authentifiée via OAuth 2.0 ou OpenID Connect (OIDC) standard avec Google Identity ou un fournisseur d'identité (IdP) fédéré des employés.
  • Identité de l'agent : identité SPIFFE unique et attestée par cryptographie de l'agent déployé, et certificat X.509 provisionné automatiquement, représentant l'agent agissant sous sa propre autorité.
  • Identité déléguée : contexte d'autorité combiné lorsque l'agent agit au nom de l'utilisateur humain à l'origine de la requête à l'aide d'identifiants OAuth à trois acteurs (3LO) limités, négociés par le gestionnaire d'authentification Agent Identity.

Le diagramme suivant illustre l'interaction entre l'identité de l'utilisateur, l'identité de l'agent et l'identité déléguée au niveau des limites de confiance d'entrée, d'exécution et de sortie :

Schéma de l'architecture de délégation d'identité mappant l'identité de l'utilisateur, l'identité de l'agent et l'identité déléguée entre les limites de confiance d'entrée, d'exécution et de sortie.

Dans cette architecture, l'identité de l'utilisateur établit le contexte de l'appelant lors de l'entrée, l'identité de l'agent authentifie la charge de travail dans la limite d'exécution, et l'identité déléguée combine les deux autorités lorsque l'agent accède aux services en aval au nom de l'utilisateur.

Propagation des identités au-delà des limites de confiance

Lorsqu'une requête franchit ces limites de confiance, la plate-forme évalue et propage chaque couche d'identité :

  1. Limite d'entrée client-agent (identité de l'utilisateur) : l'utilisateur humain s'authentifie auprès de l'application cliente à l'aide d'un jeton OAuth 2.0 ou OIDC. Lorsque le trafic entre par Agent Gateway (en mode d'entrée CLIENT_TO_AGENT), les règles d'autorisation associées à Agent Gateway vérifient l'identité de l'utilisateur pour confirmer qu'il est autorisé à appeler l'agent cible et à transmettre le contexte utilisateur validé à l'environnement d'exécution.
  2. Environnement d'exécution de l'agent et courtage d'identifiants (identité de l'agent) : dans l'environnement d'exécution isolé, l'agent fonctionne sous sa propre identité d'agent SPIFFE avec un certificat X.509 à rotation automatique toutes les 24 heures. Lorsque l'agent a besoin d'identifiants pour les outils en aval, il s'authentifie auprès du gestionnaire d'authentification Agent Identity à l'aide de son identité d'agent.
  3. Chemin de sortie autonome (identité de l'agent) : lorsque l'agent appelle des API Google Cloud ou des points de terminaison de machine à machine sous sa propre autorité, il s'authentifie à l'aide de jetons liés à un certificat appliqués par TLS mutuel (mTLS) et de la démonstration de preuve de possession (DPoP), de jetons d'ID OIDC ou d'identifiants OAuth à deux étapes (2LO) du gestionnaire d'authentification. Les stratégies d'autorisation et de refus IAM, les stratégies de limite d'accès des principaux (PAB) et les règles d'accès contextuel évaluent la requête strictement par rapport à l'identité de l'agent.
  4. Chemin de sortie délégué par l'utilisateur (identité déléguée) : lorsque l'agent appelle des serveurs MCP (Model Context Protocol) ou des API tierces de portée utilisateur pour le compte de l'utilisateur humain, le gestionnaire d'authentification négocie un jeton utilisateur 3LO consenti représentant l'identité déléguée. Les appels sortants sont régis à la fois par les règles de sortie de l'agent, ainsi que par les autorisations et les champs d'application OAuth consentis de l'utilisateur déléguant. Les journaux d'audit enregistrent à la fois l'identité de l'agent et celle de l'utilisateur.

Comparaison des couches d'identité

Le tableau suivant récapitule la manière dont les trois couches d'identité régissent l'accès et l'auditabilité :

Couche d'identité Type de compte principal et d'identifiants Limite de confiance et application des règles Attribution des journaux d'audit
Identité des utilisateurs Utilisateur final initiateur (compte Google ou compte principal d'identité des employés) authentifié avec un jeton OAuth 2.0 ou OIDC. Client vers agent (entrée) : les règles d'autorisation d'Agent Gateway vérifient si l'utilisateur peut appeler l'agent et lancer une session. Enregistre l'identité de l'utilisateur humain en tant qu'appelant appelant le point de terminaison de l'agent.
Identité de l'agent Charge de travail d'agent autonome (principal d'identité d'agent) authentifiée avec un certificat SPIFFE X.509 (mTLS et DPoP), un jeton d'ID OIDC, ou un identifiant 2LO ou une clé API du gestionnaire d'authentification. Agent vers n'importe où (sortie) : les stratégies d'autorisation, de refus, de limite d'accès des principaux et d'accès contextuel IAM appliquent les ressources, les fournisseurs d'authentification et les points de terminaison externes que l'agent peut atteindre de sa propre autorité. Google Cloud Enregistre le principal SPIFFE unique de l'agent en tant qu'identité active.
Identité déléguée Identité d'agent agissant au nom de l'utilisateur humain consentant (compte Google ou compte principal d'identité des employés) à l'aide d'un jeton d'accès 3LO limité géré par le gestionnaire d'authentification Agent Identity. Agent vers n'importe où (sortie) : applique l'intersection du moindre privilège. L'appel doit satisfaire à la fois aux règles de gouvernance sortantes de l'agent, aux autorisations de l'utilisateur délégué et aux champs d'application OAuth autorisés. Enregistre la double attribution, en capturant à la fois l'identité SPIFFE de l'agent et l'utilisateur humain délégué.

Étapes suivantes