Schémas de mise en réseau privé multi-agents dans Google Cloud

Last reviewed 2026-04-16 UTC

Ce document fournit des conseils pour vous aider à concevoir une infrastructure de mise en réseau privée compatible avec une application Gemini Enterprise multi-agent accessible au public, avec des connexions privées entre les agents, les sous-agents et les outils. La conception du réseau fournit des connexions privées pour les agents hébergés dans Agent Runtime sur Gemini Enterprise Agent Platform, Cloud Run, Google Kubernetes Engine (GKE), des centres de données sur site ou d'autres clouds. La conception est également compatible avec la connectivité aux agents qui s'exécutent dans des emplacements Internet.

Les systèmes d'IA multi-agents impliquent souvent des données sensibles ou propriétaires de l'organisation. La mise en réseau privée vous permet d'éviter d'exposer ce trafic à l'Internet public. Cette conception utilise l'infrastructure réseau Google Cloud , les ressources de réseau cloud privé virtuel (VPC) et la connectivité privée aux environnements sur site ou aux réseaux multicloud.

Dans la conception décrite dans ce document, les agents communiquent avec d'autres agents et avec des outils à l'aide des protocoles Agent2Agent (A2A) et MCP (Model Context Protocol). Les communications sont rendues privées en les acheminant via un réseau VPC. Pour déplacer le trafic vers et depuis le réseau VPC, cette conception utilise une combinaison de points de terminaison Private Service Connect, d'interfaces Private Service Connect et de sortie VPC directe Cloud Run. Cloud Next Generation Firewall (Cloud NGFW) gère le trafic qui transite par le réseau VPC. Des couches de sécurité supplémentaires fournissent une sortie Internet contrôlée à l'aide de Secure Web Proxy et fournissent des règles d'accès au service d'API à l'aide d'un périmètre VPC Service Controls.

Ce document s'adresse aux architectes, aux développeurs et aux administrateurs qui créent et gèrent l'infrastructure et les applications d'IA cloud. Dans ce document, nous partons du principe que vous avez des connaissances de base sur les agents IA et les modèles, et que vous connaissez les concepts de mise en réseau Google Cloud .

Modèle de conception multi-agent

Une application Gemini Enterprise multi-agent nécessite un agent personnalisé pour servir d'orchestrateur ou d'agent racine pour les connexions aux outils et aux sous-agents. Pour implémenter des connexions privées aux outils et aux sous-agents hébergés dansGoogle Cloud ou sur site, la conception utilise un réseau VPC avec des adresses IP privées. L'agent racine est hébergé dans l'infrastructure de Google, à l'aide d'Agent Engine, de Cloud Run ou de GKE. Le modèle de conception multi-agent met en évidence ces interactions :

  1. Application Gemini Enterprise interagissant avec des agents racines personnalisés Les applications Gemini Enterprise présentent une interface utilisateur gérée avec des fonctions de sécurité intégrées qui exposent les fonctionnalités des agents personnalisés. Les agents racine personnalisés sont enregistrés auprès de Gemini Enterprise et sont mis à la disposition des utilisateurs finaux dans les applications. L'agent racine personnalisé agit comme un orchestrateur de workflow de premier niveau et délègue des tâches spécialisées à des sous-agents. Cette architecture utilise des agents racine personnalisés hébergés sur Agent Runtime sur Gemini Enterprise Agent Platform, Cloud Run ou GKE.
  2. Agents racine interagissant avec des sous-agents et des outils Le cœur du workflow et de la logique métier du système d'IA réside dans l'agent racine et dans des sous-agents spécialisés. La flexibilité du framework, de l'environnement d'exécution et de la plate-forme d'hébergement de l'agent permet de connecter les agents racine aux sous-agents et aux outils de différentes manières via le réseau VPC. En utilisant un réseau VPC pour cette partie de l'architecture, les agents peuvent utiliser des chemins de réseau privé que vous définissez et qui exposent d'autres points de terminaison privés, des contrôles de sécurité d'entreprise et une meilleure joignabilité du réseau.

Présentation générale d'une architecture de mise en réseau multi-agents.

L'architecture comprend les composants suivants :

  • Application Gemini Enterprise : l'interface permettant aux utilisateurs d'accéder à une interface de chat intégrée et d'interagir avec le système d'IA multi-agent. Les utilisateurs peuvent accéder aux applications Gemini Enterprise via l'Internet public ou de manière privée via des connexions hybrides.
  • Agents personnalisés : agents racine créés et enregistrés avec Gemini Enterprise, et hébergés sur Agent Runtime, Cloud Run ou GKE. Ces agents racines fonctionnent comme des orchestrateurs qui délèguent des tâches à des sous-agents.
  • Réseau VPC : ressource que vous contrôlez pour fournir aux agents une connectivité réseau IP aux points de terminaison privés et une meilleure accessibilité au réseau. Le réseau VPC fournit une plate-forme permettant de mettre en œuvre une connectivité privée et des contrôles de sécurité réseau pour les requêtes des agents vers d'autres agents et outils.
  • Sous-agents : agents spécialisés déclenchés par le workflow de l'agent racine. Les sous-agents communiquent à l'aide du protocole A2A, qui permet l'interopérabilité entre les agents, quels que soient le langage de programmation et l'environnement d'exécution.
  • Outils : systèmes distants qui exposent des services tels que des API, des sources de données et des fonctions de workflow. Ces outils récupèrent des données et effectuent des actions ou des transactions pour les agents. Les outils sont externes aux agents, et les agents se connectent et interagissent avec les outils à l'aide de la spécification MCP.

Ce modèle de conception multi-agent de haut niveau met en évidence les composants de mise en réseau d'un système d'IA multi-agent. Il peut prendre en charge de nombreux types de modèles de routage d'agent à agent. Pour en savoir plus sur les autres modèles de conception de systèmes d'IA, consultez Choisir un modèle de conception pour votre système d'IA agentive.

VPC partagé

Le modèle de conception multi-agent utilise un VPC partagé pour centraliser l'autorité et la responsabilité en matière de mise en réseau et de sécurité. Cette conception fournit aux développeurs des environnements qui répondent aux besoins de sécurité d'une organisation. Nous vous recommandons d'utiliser un VPC partagé pour centraliser et simplifier vos configurations réseau et de sécurité.

Dans une architecture de VPC partagé, un projet hôte contient les ressources réseau partagées, y compris les réseaux VPC, les routeurs Cloud Router, les sous-réseaux, les pare-feu et Cloud DNS. Les administrateurs peuvent accorder aux projets de service l'accès à ces ressources. Les projets de service contiennent les ressources d'exécution de l'agent, y compris Agent Runtime, Cloud Run, GKE, Gemini Enterprise et les équilibreurs de charge spécifiques à l'application.

Le VPC partagé applique une limite claire entre les rôles d'administrateur réseau et de sécurité, et les rôles de développeur d'applications d'IA :

  • Les administrateurs réseau et de sécurité contrôlent l'infrastructure de base, comme le routage VPC, les sous-réseaux, l'appairage DNS et les stratégies de pare-feu.
  • Les développeurs d'applications d'IA créent des agents dans les projets de service associés sans disposer des autorisations nécessaires pour modifier l'infrastructure réseau sous-jacente.

Lorsque vous centralisez les déploiements de réseau et de sécurité dans un projet hôte, vous créez un point de gestion unique pour la communication d'agent à agent et d'agent à service. Cette conception simplifie l'application des règles de sécurité dans de nombreux projets de service différents, tout en garantissant une connectivité cohérente.

Vous pouvez intégrer votre réseau VPC partagé à un réseau Cross-Cloud en utilisant des spokes VPC Network Connectivity Center (NCC) pour ajouter le réseau VPC partagé en tant que réseau VPC de charge de travail. Cette implémentation fournit au VPC partagé une accessibilité complète aux routes du hub NCC et une connectivité aux points d'accès de service à partir d'autres spokes.

Les requêtes initiées à partir d'agents racine personnalisés utilisent un réseau VPC privé géré par le client pour fournir des chemins réseau sécurisés aux sous-agents, aux outils et aux services. Le routage du réseau VPC régit l'accessibilité aux points de terminaison privés. Les stratégies Cloud NGFW appliquées au réseau VPC régissent l'accès au réseau.

Les agents bénéficient d'un accès sécurisé aux chemins d'accès au réseau VPC privé, y compris la connectivité aux éléments suivants :

  • D'autres réseaux VPC via l'appairage de réseaux VPC, des dispositifs multi-NIC ou NCC.
  • Points de terminaison Private Service Connect pour accéder aux services du producteur.
  • Services gérés disposant d'adresses IP privées, tels que Cloud SQL.
  • Interfaces d'équilibreur de charge interne et ressources Compute Engine.
  • Google APIs via l'accès privé à Google ou Private Service Connect.
  • Internet, contrôlé via Secure Web Proxy.
  • Destinations hybrides et cross-cloud à l'aide de Cloud Interconnect, Cloud VPN, d'un appareil de routeur ou d'un SD-WAN.
  • Toute destination de point de terminaison accessible via le routage IP du réseau VPC.
  • Autres agents IA, outils et services d'assistance.

Pour en savoir plus sur le VPC partagé, consultez les ressources suivantes :

Mise en réseau de Gemini Enterprise

Les applications Gemini Enterprise sont des ressources gérées qui fonctionnent dans un environnement hébergé en dehors du réseau VPC, mais au sein du réseau de Google. Les sections suivantes décrivent la configuration de la mise en réseau entre l'utilisateur et l'application Gemini Enterprise, ainsi que la mise en réseau entre l'application et les agents.

Discussion de l'utilisateur avec les applications Gemini Enterprise

Les utilisateurs discutent avec l'application Gemini Enterprise à l'aide d'une application basée sur un navigateur qui envoie des requêtes aux API et services Google. Pour activer la connectivité utilisateur privée, vous pouvez configurer les URL des API Google de sorte qu'elles soient résolues en plages d'adresses IP privées acheminées sur votre réseau VPC. Pour en savoir plus, consultez Configurer l'accès privé à l'interface utilisateur.

Applications Gemini Enterprise aux agents personnalisés

Vous enregistrez des agents personnalisés auprès du service de découverte Gemini Enterprise. Lorsque vous enregistrez un agent, Gemini Enterprise mappe le nom de l'agent à une cible spécifique, soit l'URI de la ressource Agent Runtime, soit l'URL de l'agent A2A. Les applications Gemini Enterprise disposent d'une interface de chat intégrée appelée l'assistant. Lorsqu'un utilisateur spécifie un agent à l'aide de @agent_name ou lorsque l'assistant décide de déléguer, l'application recherche l'agent dans le registre pour trouver le point de terminaison associé.

Lorsque vous enregistrez un agent racine auprès de Gemini Enterprise, vous pouvez le déployer n'importe où en tant qu'agent personnalisé. Les agents personnalisés sur Agent Runtime et sur Cloud Run peuvent utiliser des chemins d'accès réseau privés existants sans configurer de ressources réseau supplémentaires. Pour déployer un agent personnalisé sur GKE, vous devez exposer le service avec une passerelle externe. Pour savoir comment configurer la passerelle externe pour qu'elle soit plus sécurisée, consultez la section Mise en réseau GKE plus loin dans ce document.

Pour envoyer des requêtes aux agents personnalisés, Gemini Enterprise utilise l'identité du compte de service Discovery Engine de Gemini Enterprise Agent Platform. Le chemin d'accès réseau et les mécanismes d'autorisation diffèrent en fonction de la plate-forme d'hébergement que vous utilisez :

  • Agents personnalisés sur Agent Runtime : l'agent de service Agent Platform Discovery Engine inclut les rôles IAM (Identity and Access Management) Agent Platform nécessaires pour appeler les ressources Agent Runtime en tant que fonctionnalité intégrée. Le système achemine les requêtes adressées au service de l'API Agent Platform sur le réseau Google en tant qu'appel d'API interne.
  • Agents personnalisés sur Cloud Run : les applications Gemini Enterprise utilisent l'identité de l'agent de service Discovery Engine d'Agent Platform pour appeler l'URL run.app stable enregistrée à partir de la fiche de l'agent. Pour que le service Cloud Run de l'agent IA puisse autoriser ces appels, vous devez attribuer le rôle IAM Demandeur Cloud Run (roles/run.invoker) à l'agent de service Discovery Engine. Les requêtes adressées à Cloud Run sont acheminées via le réseau de production Google vers l'entrée Google Front End (GFE) pour Cloud Run.

  • Agents personnalisés sur GKE : les applications Gemini Enterprise utilisent l'identité de l'agent de service Agent Platform Discovery Engine pour appeler l'URL enregistrée à partir de la fiche de l'agent. Le DNS public doit pouvoir résoudre le nom d'hôte en une adresse IP externe gérée par la passerelle. Nous vous recommandons d'utiliser l'équilibreur de charge gke-l7-regional-external-managed ou l'équilibreur de charge gke-l7-global-external-managed. Pour plus de sécurité, nous vous recommandons de configurer Gemini Enterprise pour qu'il appelle un agent A2A hébergé sur GKE à l'aide d'Identity-Aware Proxy (IAP). Pour qu'IAP autorise ces appels, vous devez attribuer le rôle IAM "Utilisateur de l'application Web sécurisée par IAP" (roles/iap.httpsResourceAccessor) à l'agent de service Discovery Engine. Le réseau de production Google achemine les requêtes vers GKE vers le GFE pour l'entrée de l'équilibreur de charge d'application externe.

    Pour sécuriser GKE Ingress à partir de Gemini Enterprise, consultez les sections IAP et Google Cloud Armor plus loin dans ce document.

Mise en réseau privée pour les plates-formes d'hébergement d'agents

Lorsqu'un utilisateur lance une requête dans l'application Gemini Enterprise, des requêtes sont envoyées par les agents racines personnalisés aux sous-agents et aux outils. Les plates-formes d'hébergement d'agents personnalisés fournissent l'interface entre Gemini Enterprise et vos réseaux VPC. Les plates-formes d'hébergement de vos agents et outils conteneurisés sont Agent Runtime, Cloud Run et GKE.

Lorsque vous choisissez une plate-forme d'hébergement d'agents, vous devez tenir compte des modèles de mise en réseau privés, des contrôles de sécurité, du contrôle de gestion, du niveau de personnalisation et de la conformité de sécurité de chaque plate-forme. Pour en savoir plus sur la sélection d'une plate-forme d'hébergement d'agents IA, consultez Choisir des modèles et une infrastructure pour votre application d'IA générative et Choisir les composants de votre architecture d'IA agentive.

Vous établissez une connectivité VPC privée via différents mécanismes en fonction de la plate-forme d'hébergement d'agent que vous utilisez :

  • Agents personnalisés sur Agent Runtime : les interfaces Private Service Connect connectent les environnements d'exécution Agent Runtime au réseau VPC. Vous créez un rattachement de réseau dans un sous-réseau de votre réseau VPC et autorisez Agent Runtime à s'y rattacher. Le trafic envoyé depuis Agent Runtime apparaît dans le réseau VPC comme s'il provenait de l'adresse IP du sous-réseau du rattachement. Le réseau VPC achemine ensuite le trafic vers l'adresse IP de destination appropriée.
  • Agents personnalisés sur Cloud Run : la sortie VPC directe Cloud Run connecte les instances de service Cloud Run au réseau VPC. Le réseau VPC spécifié lors du déploiement d'un service Cloud Run peut provenir du projet de service Cloud Run ou de son projet hôte de VPC partagé. Le trafic envoyé depuis Cloud Run apparaît dans le réseau VPC comme s'il provenait de l'adresse IP du sous-réseau de la sortie VPC directe. Le réseau VPC achemine ensuite le trafic vers l'adresse IP de destination appropriée.
  • Agents personnalisés sur GKE : les clusters GKE résident directement dans le réseau VPC et utilisent des adresses IP de sous-réseau locales. Par défaut, le trafic de sortie GKE utilise l'adresse IP du pod comme adresse IP source. Si vous configurez le masquage, le trafic de sortie GKE utilise l'adresse IP du nœud comme adresse IP source. Tout le trafic sortant GKE est acheminé par le réseau VPC.

Les sections suivantes fournissent des conseils supplémentaires pour gérer les requêtes d'entrée et de sortie du réseau VPC pour chaque plate-forme d'hébergement d'agent. Les considérations relatives au réseau s'appliquent à la fois aux fonctionnalités de l'agent racine et du sous-agent.

Mise en réseau d'Agent Runtime

Cette section décrit la mise en réseau privée pour les agents racine et les sous-agents hébergés sur Agent Runtime. Si vous utilisez Agent Runtime pour héberger votre agent racine, vous devez déployer Gemini Enterprise et Agent Runtime dans le même projet.

Agent Runtime héberge des conteneurs sur l'infrastructure Google en dehors de votre réseau VPC. Pour activer la connectivité privée à d'autres agents, vous pouvez connecter votre agent à votre réseau VPC à l'aide des méthodes suivantes :

Pour autoriser les requêtes entre vos agents et d'autres agents, configurez les deux connexions précédentes.

Sortie d'Agent Runtime vers le réseau VPC

Agent Runtime utilise un projet locataire géré par Google pour la sortie réseau. Le réseau locataire fournit une connectivité pour les agents aux API Google et pour la sortie Internet publique, mais il n'est pas directement connecté aux réseaux VPC du client par défaut.

Pour connecter des agents à des ressources situées dans votre réseau VPC, Agent Runtime utilise des interfaces Private Service Connect. Agent Runtime déploie une interface réseau dans le projet locataire qui se connecte à une ressource de rattachement de réseau dans votre projet. Cette connexion crée un chemin de données sécurisé entre l'environnement d'exécution Agent Runtime et le réseau VPC. Lorsque vous configurez une interface Private Service Connect dans votre projet Agent Runtime, le système achemine tout le trafic de l'agent qui n'est pas destiné aux API Google vers le réseau VPC.

Pour déployer la sortie du réseau VPC Agent Runtime, consultez les ressources suivantes :

Pour sécuriser davantage les agents et le réseau VPC pour la sortie Agent Runtime, consultez les sections suivantes de ce document :

Entrée Agent Runtime depuis le réseau VPC

Les requêtes adressées aux agents qui s'exécutent sur Agent Runtime sont effectuées à l'aide du point de terminaison de l'API Agent Platform (aiplatform.googleapis.com). Pour atteindre les points de terminaison de l'API Google à l'aide de chemins d'accès réseau privés à partir du réseau VPC, utilisez l'Accès privé à Google ou les points de terminaison Private Service Connect pour les API Google.

Les utilisateurs privés qui envoient des requêtes aux agents doivent résoudre le nom d'hôte du point de terminaison de l'API Agent Platform vers la plage d'adresses IP privées pour l'accès privé à Google ou vers l'adresse IP du point de terminaison Private Service Connect pour les API Google. Une zone Cloud DNS gérée privée pour googleapis.com résout les requêtes pour l'API Agent Platform. Le réseau VPC achemine la requête directement sur le réseau de production Google.

Si vous utilisez l'accès privé à Google ou Private Service Connect pour les API Google, vous pouvez protéger le trafic entre votre réseau VPC et Agent Runtime à l'aide des produits et fonctionnalités suivants :

Autres considérations concernant le réseau Agent Runtime

La sortie Agent Runtime qui utilise des interfaces Private Service Connect ne peut acheminer le trafic que vers des plages d'adresses IP RFC 1918 du réseau VPC. Pour connaître les plages de destination spécifiques qui ne sont pas routables par la sortie Agent Runtime, consultez Exigences concernant les plages d'adresses IP des sous-réseaux. Pour atteindre des destinations de plages d'adresses IP non routables, utilisez une configuration de proxy explicite sur les agents et déployez des ressources de proxy qui utilisent une adresse IP routable dans le réseau VPC.

Lorsque Agent Runtime est déployé sans interface Private Service Connect, il a accès à Internet par défaut. Pour vous protéger contre l'exfiltration de données, désactivez l'accès par défaut en activant VPC Service Controls.

Lorsque l'Agent Runtime est déployé avec une interface Private Service Connect, la sortie Internet directe est désactivée, indépendamment de VPC Service Controls. Si vous avez besoin que votre agent accède à une destination qu'Agent Runtime ne peut normalement pas atteindre, comme Internet, procédez comme suit :

  1. Configurez Secure Web Proxy dans un sous-réseau RFC 1918 de votre réseau VPC. Vous devez configurer le proxy en mode de routage proxy explicite.
  2. Créez un enregistrement Cloud DNS pour le nom d'hôte du proxy Web sécurisé.
  3. Configurez l'appairage DNS pour Agent Runtime afin de permettre la résolution des requêtes DNS de l'agent vers l'adresse privée de Secure Web Proxy dans le réseau VPC.
  4. Lorsque vous déployez des agents, procédez comme suit :
    1. Définissez des variables d'environnement pour utiliser le proxy explicite en spécifiant le nom d'hôte et le port de Secure Web Proxy.
    2. Si vous accédez à une destination privée, configurez une zone DNS privée pour cette destination.

Une fois que le trafic provenant de la sortie d'Agent Runtime atteint le réseau VPC, il peut atteindre n'importe quelle destination réseau routable par le réseau VPC. Pour savoir comment limiter le champ d'application des destinations réseau de sortie disponibles pour les agents Agent Runtime, consultez la section Cloud NGFW plus loin dans ce document.

Mise en réseau Cloud Run

Cette section décrit la mise en réseau privée pour les agents racine et les sous-agents hébergés sur Cloud Run. Cloud Run héberge des conteneurs sur l'infrastructure Google en dehors de votre réseau VPC. Pour activer la connectivité privée à d'autres agents, vous pouvez connecter votre agent à votre réseau VPC à l'aide des méthodes suivantes :

Pour autoriser les requêtes entre vos agents et d'autres agents, configurez les deux connexions précédentes.

Sortie Cloud Run vers le réseau VPC

Pour initier des connexions Cloud Run vers un réseau VPC, nous vous recommandons d'utiliser la sortie VPC directe. Avec la sortie VPC directe, les instances Cloud Run se connectent directement au réseau VPC partagé à l'aide d'une adresse IP du sous-réseau que vous spécifiez lorsque vous déployez la sortie VPC directe.

Lorsque vous configurez la sortie VPC directe, procédez comme suit :

  1. Configurez le sous-réseau cible avec l'accès privé à Google activé.
  2. Configurez le routage du trafic pour acheminer tout le trafic vers le réseau VPC.

Cette configuration envoie tout le trafic via le réseau VPC pour des raisons de confidentialité et envoie les requêtes de Cloud Run vers d'autres API Google via le réseau interne de Google.

Toutes les requêtes DNS de Cloud Run utilisent la règle et les zones Cloud DNS associées au réseau VPC. Aucune configuration d'appairage DNS supplémentaire n'est requise. Les agents hébergés sur Cloud Run résolvent toutes les zones privées et tous les noms d'hôte publics Cloud DNS.

Pour savoir comment sécuriser davantage les agents et le réseau VPC pour la sortie Cloud Run, consultez les sections suivantes de ce document :

Trafic d'entrée Cloud Run provenant du réseau VPC

Cloud Run est une plate-forme gérée par Google qui fonctionne dans un environnement extérieur au réseau VPC. Cet environnement héberge le point de terminaison d'URL *.run.app stable pour les services Cloud Run qui exécutent des charges de travail d'agent IA ou d'outil. Ces points de terminaison sont diffusés par le même point d'entrée GFE que celui qui diffuse les services d'API *.googleapis.com. Cloud Run utilise les mêmes chemins réseau sous-jacents qui permettent la connectivité privée pour l'accès privé à Google et pour Private Service Connect pour les API Google.

Les utilisateurs privés du réseau VPC qui envoient des requêtes aux agents ou aux outils doivent résoudre le nom d'hôte run.app vers la plage d'adresses IP privées pour l'accès privé à Google ou vers l'adresse IP du point de terminaison Private Service Connect pour les API Google. Une zone Cloud DNS gérée privée pour l'URL run.app résout les requêtes pour les services Cloud Run. Le réseau VPC achemine la requête directement sur le réseau de production Google.

Définir l'entrée Cloud Run sur Interne limite l'accès à votre service en n'autorisant que les requêtes provenant de sources internes validées. Les sources approuvées incluent les éléments suivants :

  • Réseaux VPC du projet de service Cloud Run.
  • Réseau VPC partagé qui héberge le point de terminaison de sortie VPC directe.
  • Ressources situées dans le même périmètre VPC Service Controls.
  • Équilibreurs de charge d'application internes dans le réseau VPC.
  • Services Google tels que Cloud Scheduler et Pub/Sub qui se trouvent dans le projet de service ou le périmètre VPC Service Controls.

Si vous n'utilisez pas de périmètre VPC Service Controls commun pour englober à la fois les services appelants et appelés, le trafic provenant de l'extérieur du projet de service Cloud Run ou de l'environnement VPC partagé est traité comme externe. Cela inclut le trafic provenant d'autres services Google Cloud, tels qu'Agent Runtime et d'autres services Cloud Run. Pour satisfaire la vérification de l'entrée interne Cloud Run, ce trafic doit être acheminé de manière à sembler provenir du réseau VPC du service cible.

Pour fournir l'attribution de réseau interne nécessaire, vous pouvez effectuer l'une des opérations suivantes :

  • Utilisez des points de terminaison Private Service Connect pour permettre aux services d'autres VPC ou projets de se connecter aux API et services Google, y compris à votre service Cloud Run, à l'aide d'une adresse IP privée au sein de votre réseau VPC.
  • Acheminez le trafic via un équilibreur de charge d'application interne placé dans votre réseau VPC devant votre service Cloud Run. L'équilibreur de charge achemine les requêtes d'autres services via le réseau VPC afin qu'elles répondent aux critères d'entrée interne.

Les équilibreurs de charge d'application internes avec des backends de groupe de points de terminaison du réseau (NEG) sans serveur créent une ressource VPC mappée directement à un service Cloud Run. Dans ce modèle, l'équilibreur de charge met fin aux connexions TLS des clients avec un certificat de confiance. Les équilibreurs de charge d'application internes sont compatibles avec des contrôles de sécurité supplémentaires, y compris les règles de sécurité de backend Cloud Armor et des règles d'autorisation supplémentaires.

Par défaut, l'accès à tous les services Cloud Run nécessite une authentification IAM. Nous vous recommandons d'utiliser une identité par service et d'accorder au compte principal le rôle IAM Demandeur Cloud Run (roles/run.invoker).

Pour savoir comment configurer les contrôles d'entrée Cloud Run, consultez les ressources suivantes :

Si vous utilisez l'accès privé à Google ou des points de terminaison Private Service Connect pour les API Google afin d'envoyer du trafic de votre réseau VPC vers Cloud Run, vous pouvez protéger ce trafic à l'aide des produits et fonctionnalités suivants :

Si vous utilisez un équilibreur de charge d'application interne pour envoyer du trafic de votre réseau VPC vers Cloud Run, vous pouvez protéger ce trafic à l'aide des produits et fonctionnalités suivants :

Mise en réseau GKE

Cette section décrit la mise en réseau des agents basés sur GKE.

GKE et Gemini Enterprise

En tant qu'hôte pour les agents IA et les outils, GKE offre une plate-forme hautement personnalisable pour les contrôles réseau et de sécurité. Un système d'IA multi-agent déployé sur GKE peut offrir une efficacité opérationnelle à grande échelle. Il peut s'intégrer étroitement à d'autres applications Kubernetes et à des architectures de microservices plus vastes.

Les clusters GKE sont des nœuds de VM Compute Engine qui s'exécutent dans un sous-réseau du réseau VPC. Les applications Gemini Enterprise sont des ressources gérées qui fonctionnent dans un environnement hébergé en dehors du réseau VPC. Pour permettre aux applications Gemini Enterprise d'appeler des agents personnalisés hébergés sur GKE, vous devez exposer de manière sécurisée une passerelle externe avec une adresse IP publique et un nom DNS. Le trafic circule de la sortie Gemini Enterprise vers le réseau en périphérie de Google, où il emprunte une route optimisée vers l'équilibreur de charge externe GKE.

Il est important de sécuriser le point de terminaison GKE en utilisant une authentification et une autorisation fortes, Cloud Armor et des autorisations limitées. Pour fournir un modèle de défense en profondeur complet permettant de sécuriser les agents IA qui s'exécutent sur GKE, tenez compte des contrôles de sécurité décrits dans les sections suivantes.

Mode de fonctionnement GKE

GKE propose ces modes de fonctionnement pour équilibrer la gestion et le contrôle :

  • Autopilot : Google automatise l'ensemble de l'infrastructure de cluster GKE, y compris le plan de contrôle, le provisionnement des nœuds, le renforcement de la sécurité et le scaling.
  • Standard : Google gère le plan de contrôle. Vous conservez l'entière responsabilité des configurations des pools de nœuds, comme la sélection des types de machines, la gestion des images de l'OS et le scaling manuel.
Renforcement de l'infrastructure et du plan de contrôle
  • Clusters GKE privés : provisionnez des nœuds sans adresse IP publique, ce qui garantit que l'environnement d'exécution est isolé de l'exposition directe à Internet.
  • Réseaux autorisés maîtres : limitez l'accès administratif à l'API Kubernetes à des plages d'adresses IP spécifiques et de confiance, ce qui renforce le plan de contrôle contre les modifications de configuration non autorisées. Sécurisez le point de terminaison DNS pour l'API Kubernetes à l'aide d'IAM et de VPC Service Controls de Google Cloud.
Identité et accès (zéro confiance)
  • IAP : agit comme un contrôleur d'accès au niveau de l'équilibreur de charge. Il garantit que seuls les utilisateurs authentifiés disposant des autorisations IAM appropriées peuvent accéder au point de terminaison de l'agent. Cette approche déplace efficacement le périmètre de sécurité du réseau vers l'utilisateur individuel et le contexte de son appareil.
Protection périphérique et gestion du trafic
  • Cloud Armor : fournit une sécurité robuste en périphérie, y compris des règles de pare-feu d'application Web (WAF) pour bloquer les charges utiles malveillantes, une protection DDoS pour garantir le temps d'activité et une limitation du débit pour éviter l'épuisement des services.
  • Model Armor : spécialement conçu pour la sécurité des LLM, Model Armor inspecte et nettoie les prompts et les réponses en temps réel pour empêcher l'injection de prompt et l'exfiltration de données.
Isolation du réseau interne
  • Règles de réseau Kubernetes : applique une communication précise et basée sur le principe du moindre privilège entre les microservices. Par défaut, les règles refusent tout le trafic, sauf si vous l'autorisez explicitement, ce qui empêche les déplacements latéraux au sein du cluster.

Sortie GKE vers le réseau VPC

Le réseau VPC achemine les connexions sortantes des agents hébergés sur GKE. Le mode réseau par défaut des clusters GKE est VPC natif, qui fournit les attributs suivants :

  • Le cluster GKE utilise des plages d'adresses IP d'alias.
  • Les adresses IP des pods sont réservées en spécifiant la plage d'adresses IP des pods.
  • Les adresses IP des pods sont nativement routables sur le réseau VPC du cluster et sur les autres réseaux VPC connectés.

Si un pod d'agent communique avec un pod de sous-agent sur le même nœud, le trafic est acheminé localement dans l'espace de noms réseau du nœud. Si le pod de l'agent de destination se trouve sur un autre nœud du cluster, le trafic est acheminé à l'aide de la table de routage du réseau VPC. Pour qu'un pod d'agent puisse communiquer avec d'autres ressources VPC telles que des équilibreurs de charge ou des points de terminaison Private Service Connect, il peut atteindre la destination en utilisant le même routage VPC standard, sous réserve des règles de pare-feu.

Vous pouvez protéger le trafic qui quitte votre cluster GKE à l'aide des produits et services suivants :

Entrée GKE depuis le réseau VPC

Les services Kubernetes permettent d'accéder aux ressources GKE. Pour un système d'IA multi-agent, nous vous recommandons d'utiliser une passerelle GKE ou une passerelle d'inférence GKE. La passerelle fournit des fonctionnalités améliorées avec le contrôle du trafic, la séparation opérationnelle des ressources et les intégrations de sécurité. Toutefois, d'autres options de service d'entrée sont disponibles en fonction de la configuration système requise.

La ressource Gateway crée un équilibreur de charge d'application et provisionne tous les composants d'équilibrage de charge nécessaires. Les groupes de points de terminaison du réseau de backend du service sont connectés pour fournir un équilibrage de charge directement aux conteneurs. Pour exposer un service en interne pour le trafic provenant du réseau VPC, utilisez les classes Gateway pour l'équilibreur de charge d'application interne régional (gke-l7-rilb) ou l'équilibreur de charge d'application interne interrégional (gke-l7-cross-regional-internal-managed-mc).

Les équilibreurs de charge d'application fournissent des points de contrôle de sécurité supplémentaires pour protéger les agents IA et les outils hébergés sur des clusters GKE :

  • Cloud Armor : protège les services en associant une stratégie de sécurité Cloud Armor aux services de backend gérés par la passerelle. Il fournit un filtrage WAF, un filtrage basé sur l'adresse IP et la géolocalisation, une protection DDoS et une limitation du débit avant que le trafic n'atteigne le cluster GKE ou IAP.
  • IAP : activé sur le service de backend pour contrôler l'accès aux applications à l'aide d'identifiants IAM, IAP applique des règles d'accès zéro confiance. IAP authentifie et autorise les agents IA qui accèdent aux ressources du cluster, y compris les applications Gemini Enterprise, les agents personnalisés et les ressources externes. Les appelants doivent disposer d'une identité authentifiée par IAM et d'une autorisation d'accès au service de backend.

Si vous envoyez du trafic de votre réseau VPC vers votre service GKE via une passerelle, vous pouvez protéger ce trafic à l'aide des produits et fonctionnalités suivants :

Si vous n'utilisez pas de passerelle pour envoyer du trafic de votre réseau VPC vers votre service GKE, vous pouvez protéger ce trafic à l'aide des produits et services suivants :

Pour en savoir plus sur la sécurisation de GKE, consultez les bonnes pratiques en matière de sécurité réseau et Comprendre la sécurité réseau dans GKE.

Sécurité réseau de l'agent

Pour protéger le réseau d'un système d'IA multi-agent, vous devez sécuriser les communications via le réseau VPC et la surface de l'API. Le plan de données du réseau VPC gère la manière dont les agents et les outils se connectent de manière sécurisée. La surface de l'API définit les identités et les types d'échanges de données autorisés. La superposition des contrôles d'accès sur le réseau VPC et la surface de l'API permet d'appliquer une stratégie de sécurité hautement contrôlée et résiliente.

Cloud NGFW

Cloud NGFW agit comme un gardien au niveau du réseau pour sécuriser les communications A2A et MCP. Le pare-feu garantit que seul le trafic autorisé peut atteindre les points de terminaison de l'agent en vérifiant chaque connexion entrante ou sortante vers et depuis d'autres agents et outils.

Cloud NGFW est un service de pare-feu distribué intégré à la structure du réseau VPC. Il propose les niveaux de fonctionnalités suivants, qui fonctionnent à différentes couches de la pile réseau :

  • Cloud Next Generation Firewall Essentials : fournit un filtrage des paquets par pare-feu avec état. Les règles de stratégie sont définies en fonction des adresses IP (L3), des protocoles et des ports (L4).
  • Cloud Next Generation Firewall Standard : fournit une application basée sur l'adresse IP avec des objets de nom de domaine complet (FQDN), des objets de géolocalisation et des flux de Google Threat Intelligence pour bloquer les adresses malveillantes connues.
  • Cloud Next Generation Firewall Enterprise : fournit de véritables fonctionnalités d'inspection des applications (L7) avec déchiffrement TLS et fonctionnalités de système de détection et de prévention des intrusions (IDPS) pour analyser les charges utiles par rapport aux signatures de menaces avancées.

Cloud NGFW peut être appliqué au réseau VPC pour appliquer une stratégie de pare-feu basée sur les règles nécessaires pour cibler la plate-forme d'hébergement d'agents que vous avez utilisée.

  • Agent Runtime : les agents qui s'exécutent dans Agent Runtime se connectent au réseau VPC à l'aide de rattachements de réseau Private Service Connect. Ces rattachements font apparaître l'interface réseau de l'agent dans un sous-réseau du réseau VPC. Les stratégies de pare-feu de réseau Cloud NGFW sont appliquées au réseau VPC. Les règles filtrent le trafic en fonction des adresses IP sources du sous-réseau dédié au rattachement de réseau Private Service Connect. Pour la mise en correspondance du trafic, vous pouvez utiliser des plages d'adresses IP sources et d'adresses IP de destination.
  • Cloud Run : les services Cloud Run qui utilisent la sortie VPC directe envoient le trafic directement depuis les instances qui s'exécutent dans un sous-réseau spécifié dans le réseau VPC. Les stratégies de pare-feu de réseau Cloud NGFW s'appliquent au sous-réseau utilisé par Cloud Run pour filtrer le trafic. Pour la mise en correspondance du trafic, vous pouvez utiliser des plages d'adresses IP sources et d'adresses IP de destination.
  • GKE : les clusters GKE de VPC natif attribuent aux pods des adresses IP provenant directement des plages d'adresses IP secondaires du réseau VPC. Les stratégies de pare-feu réseau peuvent filtrer le trafic en fonction des plages d'adresses IP des nœuds et des pods GKE. Elles peuvent utiliser des tags sécurisés et des comptes de service. Les tags sécurisés sont liés aux instances de VM qui agissent en tant que nœuds GKE. Les règles de pare-feu peuvent ensuite cibler ou sourcer le trafic provenant de nœuds dotés de tags spécifiques. Les règles de pare-feu peuvent également cibler ou sourcer le trafic provenant de nœuds GKE en fonction de l'identité du compte de service associée au pool de nœuds.

Règle de sortie de refus par défaut

La mise en œuvre d'une stratégie de refus par défaut est une bonne pratique de sécurité qui respecte le principe du moindre privilège. Cette stratégie garantit que seul le trafic réseau explicitement autorisé est permis, tandis que tout autre trafic est bloqué par défaut. Cette implémentation est réalisée en structurant les règles de pare-feu avec des règles ALLOW de priorité élevée pour les flux légitimes connus et une règle DENY de priorité faible, qui s'applique à tous les cas. Tous les niveaux de Cloud NGFW autorisent les règles basées sur les plages d'adresses IP sources et de destination.

Les règles de stratégie de pare-feu peuvent correspondre efficacement au trafic source provenant du sous-réseau de rattachement de réseau Agent Runtime et du sous-réseau de sortie VPC directe Cloud Run.

Voici un exemple de règle de sortie de refus par défaut :

  • Créer une stratégie et des règles de pare-feu réseau : créez une stratégie de pare-feu mondiale ou régionale et associez-la au réseau VPC. Créez des règles de stratégie de pare-feu qui ciblent le trafic sortant (--direction=EGRESS) en fonction des plages d'adresses IP sources (--src-ip-ranges=SRC_IP_RANGES) et des plages d'adresses IP de destination (--dest-ip-ranges=DEST_IP_RANGES).
  • Règles ALLOW spécifiques : utilisez des numéros de priorité inférieurs, par exemple 100-1000. Ces règles autorisent précisément le trafic réseau nécessaire au fonctionnement de vos agents IA. Ce trafic inclut la communication avec d'autres services internes, des équilibreurs de charge, les API Google requises ou des points de terminaison externes légitimes. Créez une règle qui met en correspondance le trafic source provenant du sous-réseau de rattachement de réseau d'Agent Runtime ou du sous-réseau de sortie VPC directe de Cloud Run avec les destinations de votre choix.
  • Règle DENY générale : pour vous assurer que la règle est la dernière dans l'ordre d'évaluation, utilisez le numéro de priorité le plus élevé, par exemple 2147483647. Cette règle refuse le trafic vers toute destination (--dest-ip-ranges=0.0.0.0/0) qui ne correspond à aucune des règles ALLOW précédentes.

Une règle de refus de sortie par défaut empêche les agents IA d'établir des connexions réseau qui ne sont pas explicitement autorisées, et bloque l'exfiltration potentielle de données ou l'accès à des sites malveillants. La règle limite les agents hébergés à ne communiquer qu'avec des points de terminaison approuvés, ce qui est crucial pour garder le contrôle sur les charges de travail autonomes.

Autres considérations concernant les stratégies Cloud NGFW

Au-delà de la stratégie de refus par défaut disponible avec tous les niveaux Cloud NGFW, vous pouvez renforcer davantage la sécurité réseau de votre IA multi-agent en utilisant des fonctionnalités payantes :

  • Fonctionnalités de Cloud NGFW Standard :
    • Objets FQDN pour les points de terminaison dynamiques : les agents IA interagissent souvent avec des API externes, des points de terminaison de modèle ou des sources de données dont les adresses IP peuvent changer. Pour un accès cohérent aux services nécessaires par nom de domaine, utilisez des objets FQDN dans les règles ALLOW.
    • Contrôles de géolocalisation : si les agents IA sont soumis à des exigences de conformité ou s'ils ne doivent pas interagir avec des services dans des régions géographiques spécifiques, utilisez des objets de géolocalisation (--src-region-codes=SRC_COUNTRY_CODES) dans vos règles de pare-feu pour limiter le trafic vers ou depuis ces emplacements.
    • Google Threat Intelligence : utilisez Google Threat Intelligence dans les filtres de sortie pour empêcher automatiquement les agents de se connecter à des destinations malveillantes connues, telles que des serveurs de commande et contrôle (C2), des anonymiseurs comme Tor et des sites de distribution de logiciels malveillants. L'utilisation de Google Threat Intelligence permet de limiter l'impact d'un agent potentiellement compromis. Nous vous recommandons d'inclure ces filtres de destination dans les règles DENY de priorité plus élevée (ordre d'évaluation inférieur).
  • Fonctionnalités de Cloud NGFW Enterprise :
    • Inspection de couche 7 : pour les agents qui gèrent des données sensibles ou qui sont exposés à des risques plus élevés, inspectez les charges utiles des paquets pour détecter les menaces telles que les logiciels malveillants, les logiciels espions et les exploits qui ne sont pas analysés par les règles de pare-feu de la couche réseau.
    • Inspection TLS : pour permettre au moteur d'inspection d'analyser le trafic chiffré, activez l'inspection TLS. L'utilisation de l'inspection TLS est cruciale, car la plupart des attaques modernes et des communications C2 sont chiffrées.

Pour en savoir plus sur les considérations ou les limites de mise en œuvre susceptibles de s'appliquer à votre environnement, consultez les ressources suivantes :

IAP

IAP sécurise les requêtes d'entrée vers les clusters GKE en fournissant une couche d'authentification et d'autorisation centrale pour les applications d'IA. IAP intercepte toutes les requêtes HTTPS destinées à la passerelle, puis vérifie l'identité et les autorisations de l'appelant. IAP n'autorise que les requêtes authentifiées et autorisées à accéder à la charge de travail du service de backend. IAP sur l'équilibreur de charge de la passerelle ne protège que le trafic provenant de l'extérieur du cluster. La communication au sein du cluster ne passe pas par IAP.

Pour accéder aux applications d'IA hébergées sur GKE et protégées par IAP, les identités des utilisateurs principaux doivent disposer du rôle IAM Utilisateur de l'application Web sécurisée par IAP (roles/iap.httpsResourceAccessor) sur la ressource de service de backend protégée par IAP. Nous vous recommandons de configurer un compte de service personnalisé en tant qu'identité pour les agents déployés. L'utilisation d'un compte de service personnalisé vous permet d'attribuer des autorisations plus précisément, conformément au principe du moindre privilège.

N'accordez le rôle IAM d'utilisateur de l'application Web sécurisée par IAP qu'aux comptes de service des agents autorisés à accéder aux autres agents et outils hébergés sur la ressource personnalisée GKE BackendConfig. Pour autoriser l'accès aux applications Gemini Enterprise, accordez des autorisations en associant le rôle IAM Compte de service Discovery Engine (roles/discoveryengine.serviceAgent) à votre projet Gemini Enterprise.

VPC Service Controls

VPC Service Controls limite les risques d'exfiltration de données en contrôlant strictement l'accès aux API Google. Nous vous recommandons de déployer un seul macro-périmètre incluant tous les services compatibles. Cette approche offre la défense la plus robuste contre l'exfiltration. Pour garantir une application cohérente des règles pour les architectures de VPC partagé, il est essentiel d'inclure à la fois le projet hôte et tous les projets de service associés dans le même périmètre de service.

Pour sécuriser l'interaction entre Gemini Enterprise et Cloud Run au-delà des limites du projet, tenez compte des recommandations suivantes :

  • Déployez un seul périmètre VPC Service Controls qui englobe à la fois les projets Gemini Enterprise et Cloud Run.
  • Ajoutez tous les services VPC Service Controls compatibles à la liste des services restreints. Cette approche permet d'éviter les modifications administratives non autorisées.
  • Appliquez les paramètres d'entrée et d'autorisation internes pour bloquer tout accès Internet public à vos services Cloud Run.

Les services Cloud Run sont sécurisés par IAM. Les appelants doivent être authentifiés et disposer du rôle IAM Demandeur Cloud Run (roles/run.invoker) sur le service cible. Le rôle est vérifié en validant un jeton de l'en-tête Authorization. Pour appeler correctement le service Cloud Run, les comptes de service, tels que ceux utilisés par Gemini Enterprise, doivent également disposer du rôle "Demandeur Cloud Run".

Lorsque Gemini Enterprise et Cloud Run sont déployés dans des projets différents, un périmètre VPC Service Controls est requis pour définir l'entrée Cloud Run sur "Interne". Sans ce périmètre, les appels multiprojets de Gemini sont traités comme du trafic externe, ce qui vous oblige à définir l'entrée Cloud Run sur "Tous", ce qui expose le service à l'Internet public.

  • L'entrée Cloud Run all est compatible lorsque les deux conditions suivantes sont vraies :
    • VPC Service Controls n'est pas activé.
    • Cloud Run et Gemini Enterprise ne se trouvent pas dans le même projet.
  • Seul l'objet d'entrée Cloud Run internal est compatible avec toutes les autres configurations.

Autres points à prendre en compte concernant VPC Service Controls

Lorsque Cloud Run est déployé dans un périmètre VPC Service Controls, nous vous recommandons de mettre en œuvre les garde-fous suivants pour assurer une protection complète :

  • Limiter les paramètres d'entrée autorisés : empêchez les développeurs de déployer accidentellement des points de terminaison publics en définissant la contrainte de règle d'administration run.allowedIngress. Cette contrainte ne s'applique qu'aux nouveaux déploiements. Les déploiements antérieurs peuvent ne pas être conformes. Nous vous recommandons d'auditer tous les services Cloud Run existants dans le périmètre, puis de redéployer ou de mettre à jour ceux qui ne respectent pas les paramètres d'entrée et de sortie requis.
    • Pour n'autoriser que les requêtes internes, définissez la valeur sur internal.
    • Pour autoriser les requêtes via un équilibreur de charge d'application externe, définissez la valeur sur internal-and-cloud-load-balancing.
  • Limiter les paramètres de sortie VPC autorisés : pour acheminer toutes les requêtes sortantes via le VPC afin qu'elles puissent être inspectées par les règles de pare-feu du périmètre, définissez la valeur de la contrainte de règle d'administration run.allowedVPCEgress sur all-traffic. Ce paramètre exige que chaque révision Cloud Run utilise la sortie VPC directe ou un connecteur d'accès au VPC sans serveur. Cette contrainte ne s'applique qu'aux nouveaux déploiements. Il est possible que les déploiements antérieurs ne soient pas conformes. Nous vous recommandons d'auditer tous les services Cloud Run existants dans le périmètre, et de redéployer ou de mettre à jour ceux qui ne respectent pas les paramètres d'entrée et de sortie requis.
  • Colocaliser les images de conteneurs et les services : le dépôt Artifact Registry qui contient vos images de conteneurs doit se trouver dans le même périmètre que le service Cloud Run. L'extraction d'images entre périmètres est automatiquement bloquée, sauf si vous établissez des règles d'entrée et de sortie explicites.
  • Gérer les niveaux d'accès : les règles de stratégie d'entrée VPC Service Controls et les niveaux d'accès qui reposent sur des identités de comptes principaux IAM ne sont pas compatibles avec les appels Cloud Run. Vous devez plutôt gérer l'accès à l'aide de critères basés sur le réseau ou de niveaux d'accès basés sur l'appareil.

Model Armor

Model Armor est un service basé sur une API qui offre une sécurité renforcée pour les applications d'IA. Les agents IA interagissent avec Model Armor en effectuant des appels pour nettoyer les prompts utilisateur avant qu'ils ne soient envoyés à un LLM et pour nettoyer les réponses du modèle avant qu'elles ne soient renvoyées à l'utilisateur. Model Armor filtre activement les prompts et les réponses des LLM, ce qui fournit un point d'inspection important pour détecter les risques émergents et un point de contrôle pour mettre en œuvre des normes d'IA responsable. Nous vous recommandons d'utiliser Model Armor pour assurer la conformité avec les exigences de résidence des données et les réglementations légales sur la souveraineté des données. Pour utiliser Model Armor dans un périmètre VPC Service Controls, vous devez configurer un point de terminaison Private Service Connect pour le point de terminaison régional Model Armor dans votre réseau VPC.

Model Armor est un service régional accessible de manière privée via des points de terminaison Private Service Connect régionaux dans le réseau VPC. Par exemple, le service us-central1 est appelé à l'aide du point de terminaison régional modelarmor.us-central1.rep.googleapis.com. Les points de terminaison régionaux permettent de garantir la résidence des données.

Pour permettre aux agents d'accéder au service Model Armor, configurez les composants suivants dans chaque région où le service est requis :

  1. Créez ou identifiez un sous-réseau RFC 1918 dans la région du réseau VPC où se trouve le service Model Armor.
  2. Créez un point de terminaison régional dans le sous-réseau RFC 1918.
  3. Créez une zone privée Cloud DNS et un enregistrement pour le nom d'hôte du point de terminaison régional Model Armor (par exemple, modelarmor.us-central1.rep.googleapis.com) qui se résout en l'adresse IP du point de terminaison régional.
  4. Pour l'interopérabilité d'Agent Runtime, établissez un appairage DNS entre Agent Runtime et la zone privée Cloud DNS associée à votre réseau VPC. Lorsque les agents envoient des requêtes à Model Armor, Cloud DNS résout les requêtes de nom d'hôte vers l'adresse IP du point de terminaison régional Private Service Connect dans le réseau VPC. Cette étape n'est pas obligatoire pour les agents hébergés dans Cloud Run et GKE.

Pour intégrer Gemini Enterprise à Model Armor, créez un modèle Model Armor dans le même projet que Gemini Enterprise. L'emplacement du modèle et de l'application Gemini Enterprise doit être identique.

Pour en savoir plus sur l'activation de Model Armor, consultez les ressources suivantes :

Cloud Armor

Cloud Armor est un service de sécurité réseau distribué qui protège les applications et les services situés derrière des équilibreurs de charge avant que les requêtes n'atteignent les environnements d'exécution des service de backend. Les charges de travail des agents IA impliquent des volumes élevés de communication interservices qui utilisent des appels A2A, MCP et d'API. La protection Cloud Armor fournit des couches de résilience supplémentaires dans la conception de la sécurité, avec une limitation du débit, un filtrage WAF et des règles personnalisées conformes aux requêtes d'agent attendues. En associant des stratégies de sécurité Cloud Armor aux services de backend de l'équilibreur de charge d'application, vous pouvez filtrer le trafic pour détecter les requêtes malveillantes, appliquer des limites de débit et atténuer les attaques DDoS.

Cloud Armor peut être déployé dans une architecture de réseau d'agents dans les scénarios suivants :

  • Cloud Run avec un équilibreur de charge d'application interne : protégez les agents et les outils qui s'exécutent sur Cloud Run en utilisant un équilibreur de charge d'application interne avec des backends NEG sans serveur. Appliquez des stratégies de sécurité de backend au NEG sans serveur pour appliquer des règles WAF au trafic interne et à la limitation du débit. Pour contrôler les communications des agents, vous pouvez définir des règles personnalisées supplémentaires basées sur les adresses IP et les en-têtes.
  • Passerelle : protégez les agents et les outils qui s'exécutent sur GKE en utilisant une définition de ressource Gateway pour un équilibreur de charge d'application externe global ou régional avec des backends de NEG zonaux. Utilisez l'API Kubernetes Gateway pour appliquer la ressource GCPBackendPolicy avec la stratégie de sécurité Cloud Armor définie. Si vous utilisez un équilibreur de charge d'application externe régional, Cloud Armor accepte les stratégies de sécurité de backend avec des règles WAF, des contrôles basés sur l'adresse IP et la géolocalisation, et une limitation du débit. Les équilibreurs de charge d'application externes globaux sont compatibles avec les stratégies de sécurité de backend et les stratégies de sécurité périphériques supplémentaires avec Google Cloud Armor Adaptive Protection et Google Threat Intelligence.

Secure Web Proxy

Secure Web Proxy est un service géré régional déployé dans le réseau VPC pour filtrer le trafic HTTP/S provenant du réseau VPC ou de tout réseau connecté. Il agit comme un proxy centralisé et un point d'application de la sécurité pour fournir un contrôle et une visibilité précis du trafic Internet sortant. Il sert également de proxy explicite pour les communications des services internes.

Secure Web Proxy est compatible avec trois modes de déploiement : le mode de routage proxy explicite, le mode de rattachement de service Private Service Connect et le mode de saut suivant. Nous vous recommandons d'utiliser Secure Web Proxy en mode de routage proxy explicite, qui est l'objet de ce document. Dans ce mode, les clients HTTP doivent être explicitement configurés pour pointer directement vers l'adresse IP ou le nom d'hôte de Secure Web Proxy.

Pour déployer Secure Web Proxy dans votre réseau VPC, vous devez configurer un sous-réseau d'interface et un sous-réseau proxy réservé. Secure Web Proxy est un service entièrement géré. Lorsque Secure Web Proxy est déployé, il déploie et configure automatiquement Cloud Router et Cloud NAT dans votre réseau VPC pour une intégration spécifique à la ressource de proxy. Cette configuration exige que toutes les requêtes sortantes passent par Secure Web Proxy avant de sortir vers Internet.

L'utilisation de Secure Web Proxy en tant que proxy explicite est compatible avec les requêtes d'agent provenant des interfaces Private Service Connect d'Agent Runtime, de la sortie VPC directe Cloud Run et des clusters GKE de VPC natif. Lorsque les agents envoient des requêtes à Secure Web Proxy à l'aide de la méthode HTTP CONNECT, le trafic de la session TCP est acheminé via un tunnel vers le proxy où les règles de sécurité sont appliquées. Si le trafic est autorisé, Secure Web Proxy l'envoie vers la sortie Internet contrôlée ou vers des destinations de réseau privé routables par le réseau VPC.

Routage de proxy explicite

La sortie Agent Runtime nécessite l'utilisation d'une configuration de proxy explicite pour que les agents puissent atteindre des destinations Internet ou des plages d'adresses IP non routables dans le réseau VPC. Pour l'interopérabilité d'Agent Runtime, nous vous recommandons de configurer la ressource Secure Web Proxy avec une adresse IP RFC 1918 provenant d'un sous-réseau d'interface du réseau VPC. Avec cette configuration, Secure Web Proxy devient directement accessible depuis Agent Runtime. Il peut ensuite servir de proxy pour toutes les connexions à des destinations d'adresses IP non routables qui se trouvent dans le réseau VPC ou dans les réseaux connectés.

Pour permettre à la plate-forme d'hébergement d'agents d'utiliser Secure Web Proxy en mode de routage explicite, configurez les ressources réseau suivantes :

  1. Créez ou identifiez un sous-réseau RFC 1918 dans le réseau VPC pour héberger la ressource Secure Web Proxy.
  2. Créez un enregistrement Cloud DNS pour le nom d'hôte du proxy Web sécurisé (par exemple, swp.example.com) qui pointe vers l'adresse IP de la ressource de proxy Web sécurisé.
  3. Pour l'interopérabilité d'Agent Runtime, établissez un appairage DNS entre Agent Runtime et la zone privée Cloud DNS associée à votre réseau VPC. Lorsque les agents envoient des requêtes à Secure Web Proxy, Cloud DNS résout les requêtes de nom d'hôte en adresse IP de la ressource Secure Web Proxy dans le réseau VPC. Cette étape n'est pas obligatoire pour les agents hébergés dans Cloud Run et GKE.

Paramètres de proxy de l'agent

La méthode standard pour configurer les applications d'agent afin qu'elles utilisent un proxy HTTP(S) consiste à définir les variables d'environnement suivantes :

  • HTTP_PROXY : URL du serveur proxy explicite pour le trafic HTTP (par exemple, http://swp.example.com:8888). Cette configuration utilise la méthode HTTP CONNECT du client vers le proxy. Même si HTTP est spécifié, le chiffrement TLS est maintenu de bout en bout via le proxy, de l'environnement d'exécution de l'agent au point de terminaison cible.
  • HTTPS_PROXY : URL du serveur proxy explicite pour le trafic HTTPS (par exemple, https://swp.example.com:8888). Comme le paramètre HTTP_PROXY, le paramètre HTTPS_PROXY utilise TLS par défaut. Toutefois, vous pouvez fournir une couche de chiffrement supplémentaire en activant votre propre chiffrement TLS en plus du chiffrement TLS par défaut. Pour en savoir plus, consultez Certificate Authority Service.
  • NO_PROXY : liste de noms d'hôte ou d'adresses IP séparés par une virgule qui ne doivent pas passer par le proxy. Par exemple, si vous ajoutez metadata.google.internal et 169.254.169.254 à la liste NO_PROXY, les charges de travail peuvent accéder directement au service de métadonnées pour l'authentification et l'autorisation auprès des API et services Google.

Lorsque vous utilisez l'argument env_vars pour définir des variables lors du déploiement, elles deviennent disponibles dans l'environnement d'exécution de l'agent (par exemple, lorsque vous utilisez os.environ en Python). La plupart des bibliothèques clientes HTTP standards détectent et utilisent automatiquement ces variables d'environnement pour acheminer le trafic via le proxy spécifié. Cette approche est courante pour les applications Python et les bibliothèques clientes HTTP telles que requests. Lorsque vous déployez des agents, définissez des variables d'environnement pour utiliser Secure Web Proxy pour tous les domaines privés que les agents doivent atteindre. Assurez-vous que toutes les destinations de domaine privé sont également incluses dans Cloud DNS.

L'exemple suivant montre un déploiement de proxy Agent Runtime à partir d'un objet agent :

## specify environment variables (dictionary)
env_vars = {
    "OTHER_VARIABLE": "OTHER_VALUE",
    "HTTP_PROXY": "http://swp.example.com:8888",
    "HTTPS_PROXY": "http://swp.example.com:8888",
    "NO_PROXY": "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"
}

remote_agent = aiplatform.agent_engines.create(
    agent=local_agent,
    config={
        "display_name": "Example agent using proxy",
        "env_vars": env_vars,
        ## ... other configs
    },
)

Cloud Run permet de définir des variables d'environnement au niveau de la révision du service. Cette approche remplace toutes les variables d'environnement portant le même nom qui ont été définies dans l'image de conteneur. Cette approche est utile pour définir des paramètres opérationnels tels que des variables de proxy au démarrage des instances de service.

L'exemple suivant montre la commande permettant de définir les variables d'environnement lorsque vous déployez un service Cloud Run :

gcloud run deploy SERVICE_NAME \
--image=IMAGE_URL \
--set-env-vars="HTTP_PROXY=http://swp.example.com:8888,HTTPS_PROXY=http://swp.example.com:8888,NO_PROXY=localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

Pour implémenter une configuration de proxy explicite dans les pods GKE, définissez une ressource ConfigMap qui spécifie les variables de proxy :

apiVersion: v1
kind: ConfigMap
metadata:
  name: agent-proxy-config
  namespace: ai-apps
data:
  HTTP_PROXY: "http://swp.example.com:8888"
  HTTPS_PROXY: "http://swp.example.com:8888"

  NO_PROXY: "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

Pour appliquer les clés ConfigMap aux pods, utilisez le champ envFrom dans le fichier manifeste du conteneur. Cette spécification injecte les variables d'environnement dans le conteneur au moment de l'exécution.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: subagent-app
spec:
  template:
    spec:
      containers:
      -   name: my-container
        image: my-agent-app:latest
        envFrom:
        -   configMapRef:
            name: agent-proxy-config

Service d'autorité de certification

CA Service (CA Service) est requis lorsque Secure Web Proxy ou Cloud NGFW est configuré pour l'inspection TLS. Lorsque l'inspection TLS est activée et que la destination d'une charge de travail utilise TLS, CA Service crée et signe un certificat pour cette destination. Lorsque le trafic chiffré pour la destination réelle arrive sur Secure Web Proxy ou Cloud NGFW, il déchiffre le paquet, l'inspecte, puis applique les règles. Si les règles autorisent le paquet, le service le rechiffre pour la destination finale. Vous pouvez également utiliser CA Service pour fournir des certificats à d'autres services gérés par Google.

CA Service est un service géré. Une fois CA Service configuré, il gère la signature des certificats d'entité finale jusqu'à l'expiration du certificat CA racine. Les certificats CA racine doivent être mis à jour pour s'assurer qu'ils n'expirent pas.

CA Service est compatible avec ces fonctionnalités pour permettre l'inspection du trafic et la gestion des certificats à grande échelle dans une architecture d'IA multi-agent :

  • Inspection TLS : l'utilisation d'une autorité de certification privée est requise pour l'inspection TLS complète. Pour déchiffrer et analyser entièrement les charges utiles HTTPS, l'appareil proxy intermédiaire (Secure Web Proxy ou Cloud NGFW) doit mettre fin à la session TLS avec le client. Le proxy doit présenter un certificat valide que le client accepte comme fiable pour le domaine demandé.

    CA Service peut générer et signer de manière dynamique un certificat d'emprunt d'identité spécifique au site demandé. Lorsque le certificat d'autorité de certification racine privé est installé dans le magasin de confiance du client, celui-ci accepte ce certificat créé de manière dynamique comme valide. Le client fait confiance au certificat envoyé par le proxy, il envoie donc la requête. Le proxy met fin à la session TLS, déchiffre le paquet, inspecte le contenu, puis applique les règles.

  • Distribution des certificats : les ressources client internes telles que les agents IA qui s'exécutent sur Agent Runtime, Cloud Run ou GKE doivent ajouter le certificat CA racine privé à leurs magasins de confiance locaux. En stockant la clé publique du certificat CA racine dans Secret Manager, les agents IA peuvent extraire le certificat au démarrage et l'ajouter à leur magasin de confiance système.

    Les ressources de serveur internes, telles que les équilibreurs de charge d'application internes, ont besoin de certificats émis par l'autorité de certification privée pour agir en tant que points de terminaison de serveur de confiance et mettre fin aux sessions TLS des clients. Les équilibreurs de charge d'application s'intègrent aux configurations d'émission de Certificate Manager pour automatiser la signature de la demande de certificat par CA Service et son déploiement sur l'équilibreur de charge.

Pour en savoir plus sur les opérations liées aux certificats, consultez les ressources suivantes :

Sécurité de la connexion A2A

Les agents racine communiquent avec un large éventail de sous-agents et de serveurs MCP déployés sur différentes plates-formes d'hébergement d'exécution. Chaque environnement introduit des exigences uniques en matière de mise en réseau et de sécurité qui doivent être extraites par la couche A2A ou MCP.

Le schéma suivant montre les composants et les chemins de connexion possibles compatibles avec ce guide de conception :

Modèles de connectivité Agent2Agent (A2A) entre différentes plates-formes d'hébergement, y compris GKE, Cloud Run et Agent Runtime, et connexions aux serveurs MCP et à Internet.

Le schéma précédent résume ces possibilités de connexion :

  • Les utilisateurs interagissent avec le système agentique via une application Gemini Enterprise.
  • L'application Gemini Enterprise utilise l'infrastructure Google pour se connecter à un agent racine qui s'exécute dans GKE, Cloud Run ou Agent Runtime.
  • L'application Gemini Enterprise et les agents racine utilisent l'infrastructure Google pour se connecter à Model Armor et au LLM Gemini sur Agent Platform.
  • Les agents racine peuvent utiliser l'infrastructure Google pour se connecter aux sous-agents qui s'exécutent dans Cloud Run ou Agent Runtime.
  • Les agents racine peuvent utiliser des adresses IP privées pour se connecter aux sous-agents qui s'exécutent dans Agent Runtime, Cloud Run et GKE. Ces connexions doivent être acheminées via un réseau VPC.
  • Les agents racine et les sous-agents peuvent se connecter aux serveurs MCP qui s'exécutent sur Cloud Run ou GKE. Les agents qui se connectent aux serveurs MCP peuvent utiliser l'infrastructure Google ou un réseau VPC. Les serveurs MCP permettent d'accéder à des outils hébergés dansGoogle Cloud, sur site, dans un autre cloud ou sur Internet.
  • Les services hébergés sur Internet sont accessibles directement via Secure Web Proxy.

Les sections suivantes fournissent des ressources pour les chemins de données d'exécution et les contrôles de sécurité requis pour des interactions A2A sécurisées. Ces informations servent de norme architecturale pour établir une connectivité privée et mettre en œuvre les défenses multicouches nécessaires pour protéger le chemin de données de bout en bout entre les agents.

Agent source GKE

Le tableau suivant fournit des ressources pour vous aider à protéger le trafic lorsque GKE est l'agent source. Ce trafic passe par le réseau VPC qui héberge le cluster GKE.

Agent de destination (chemin des données) Contrôle de sécurité
Agent Runtime (interne)
Cloud Run (interne)
Cloud Run (Private Service Connect pour les API Google)
Accès à Cloud Run (NEG sans serveur)
GKE
Internet via un réseau VPC

Agent source Agent Runtime (interne)

Le tableau suivant fournit des ressources pour vous aider à protéger le trafic lorsque Agent Runtime est l'agent source et que le trafic transite directement par l'infrastructure Google. Dans ces chemins, aucun réseau VPC n'est impliqué.

Agent de destination (chemin des données) Contrôle de sécurité
Agent Runtime (interne)
Cloud Run (interne)

Agent source Agent Runtime (interface Private Service Connect)

Le tableau suivant fournit des ressources pour vous aider à protéger le trafic lorsque Agent Runtime est l'agent source et que le trafic utilise une interface Private Service Connect pour transiter par un réseau VPC.

Agent de destination (chemin des données) Contrôle de sécurité
Cloud Run (Private Service Connect GoogleAPIs)
Accès à Cloud Run (NEG sans serveur)
GKE
Internet via un réseau VPC

Agent source Cloud Run (interne)

Le tableau suivant fournit des ressources pour vous aider à protéger le trafic lorsque Cloud Run est l'agent source et que le trafic transite directement par l'infrastructure Google. Dans ces chemins, aucun réseau VPC n'est impliqué.

Agent de destination (chemin des données) Contrôle de sécurité
Agent Runtime (interne)
Cloud Run (interne)

Agent source Cloud Run (sortie VPC directe)

Le tableau suivant fournit des ressources pour vous aider à protéger le trafic lorsque Cloud Run est l'agent source et que le trafic utilise la sortie VPC directe pour transiter par un réseau VPC.

Agent de destination (chemin des données) Contrôle de sécurité
Cloud Run (Private Service Connect pour les API Google)
Accès à Cloud Run (NEG sans serveur)
GKE
Internet via un réseau VPC
Private Service Connect Agent Runtime pour les API Google

Sécurité de la connexion MCP

La liste suivante décrit les plates-formes d'hébergement et les contrôles de défense en profondeur impliqués dans la sécurisation du chemin des données entre les Agent Runtimes et les serveurs MCP. Pour les agents sources dans Agent Runtime, dans Cloud Run ou dans GKE, utilisez les contrôles de sécurité suivants en fonction du serveur MCP de destination :

  • Internet :
    • VPC Service Controls
    • Model Armor
    • Cloud NGFW
    • Secure Web Proxy
  • Google MCP :
    • VPC Service Controls
    • Model Armor

Étapes suivantes

Contributeurs

Auteurs :

  • Deepak Michael | Ingénieur client spécialiste en gestion des réseaux
  • Michael Larson | Ingénieur client, spécialiste en gestion des réseaux
  • Victor Moreno | Responsable produit, Mise en réseau cloud

Autres contributeurs :