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

Last reviewed 2026-04-16 UTC

Ce document vous aide à concevoir une infrastructure réseau privée compatible avec une application Gemini Enterprise multi-agents 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 Vertex AI Agent Engine, Cloud Run, Google Kubernetes Engine (GKE), dans des centres de données sur site ou dans d'autres clouds. La conception prend également en charge la connectivité aux agents qui s'exécutent sur des emplacements Internet.

Les systèmes d'IA multi-agents impliquent souvent des données sensibles ou propriétaires pour 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 de 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 entre eux et avec les outils à l'aide du protocole Agent2Agent (A2A) et du protocole Model Context (MCP). Les communications sont rendues privées en les acheminant via un réseau VPC. Pour faire transiter 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) régit le trafic qui transite par le réseau VPC. Des couches de sécurité supplémentaires permettent de contrôler la sortie Internet à l'aide de Secure Web Proxy et de fournir des règles d'accès aux services 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 des applications et une infrastructure d'IA cloud. Dans ce document, nous partons du principe que vous avez des connaissances de base sur les agents et les modèles d'IA, et que vous êtes familiarisé avec les concepts de mise en réseau Google Cloud .

Modèle de conception multi-agents

Une application Gemini Enterprise multi-agents 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 à des outils et 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, Cloud Run ou GKE. Le modèle de conception multi-agents met en évidence les interactions suivantes :

  1. Application Gemini Enterprise interagissant avec des agents racine 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 la fonctionnalité d'agent personnalisé. Les agents racine personnalisés sont enregistrés auprès de Gemini Enterprise et mis à la disposition des utilisateurs finaux dans les applications. L'agent racine personnalisé sert d'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 Vertex AI Agent Engine, 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 les sous-agents spécialisés. La flexibilité du framework d'agent, de l'environnement d'exécution et de la plate-forme d'hébergement permet de connecter les agents racine aux sous-agents et aux outils de différentes manières via le réseau VPC. En utilisant la mise en 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 portée réseau plus large.

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

L'architecture comprend les composants suivants :

  • Application Gemini Enterprise : interface utilisateur permettant aux utilisateurs d'accéder à une interface de chat intégrée à l'application et d'interagir avec le système d'IA multi-agents. 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 Vertex AI Agent Engine, 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 portée réseau plus large. Le réseau VPC fournit une plate-forme permettant d'implémenter une connectivité privée et des contrôles de sécurité réseau pour les requêtes d'agents adressées à 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 en utilisant la spécification MCP.

Ce modèle de conception multi-agent de haut niveau met en évidence les composants réseau qui se trouvent dans un système d'IA multi-agent. Il peut prendre en charge de nombreux types de schémas 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-agents utilise le 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 les aident à répondre 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 Vertex AI Agent Engine, Cloud Run, GKE, Gemini Enterprise et les équilibreurs de charge spécifiques aux applications.

Le VPC partagé applique une limite claire entre les rôles d'administrateur réseau et de sécurité, et ceux 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, le peering DNS et les règles de pare-feu.
  • Les développeurs d'applications d'IA créent des agents dans des projets de service associés sans avoir l'autorisation de 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 entre agents et entre agents et services. Cette conception simplifie l'application des règles de sécurité dans de nombreux projets de service différents, tout en assurant une connectivité cohérente.

Vous pouvez intégrer votre réseau VPC partagé à un réseau multicloud 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 aux services à 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, outils et services. Le routage du réseau VPC régit l'accessibilité aux points de terminaison privés. Les règles 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 du réseau VPC privé, y compris à la connectivité avec les éléments suivants :

  • D'autres réseaux VPC via l'appairage de réseaux VPC, les appliances 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, comme Cloud SQL.
  • Interfaces et ressources Compute Engine de l'équilibreur de charge interne.
  • API Google via l'accès privé à Google ou Private Service Connect.
  • Internet, contrôlé par Secure Web Proxy.
  • Destinations hybrides et multicloud à l'aide de Cloud Interconnect, Cloud VPN, d'un appareil de routeur ou du SD-WAN.
  • Toute destination de point de terminaison accessible via le routage IP du réseau VPC.
  • Autres agents, outils et services d'assistance de l'IA

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

Mise en réseau 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 Google. Les sections suivantes décrivent la configuration du réseau entre l'utilisateur et l'application Gemini Enterprise, ainsi que le réseau entre l'application et les agents.

Discussion 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 afin 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'UI.

Applications Gemini Enterprise aux agents personnalisés

Vous enregistrez les 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, à savoir l' URI de la ressource Vertex AI Agent Engine ou l'URL de l'agent A2A. Les applications Gemini Enterprise disposent d'une interface de chat intégrée appelée 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 avec Gemini Enterprise, vous pouvez le déployer n'importe où en tant qu'agent personnalisé. Les agents personnalisés sur Vertex AI Agent Engine et sur Cloud Run peuvent utiliser des chemins de réseau privé 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 afin de la rendre plus sécurisée, consultez Mise en réseau GKE plus loin dans ce document.

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

  • Agents personnalisés sur Vertex AI Agent Engine : l'agent de service Vertex AI Discovery Engine inclut les rôles Vertex AI Identity and Access Management (IAM) nécessaires pour appeler les ressources Vertex AI Agent Engine en tant que fonctionnalité intégrée. Le système achemine les requêtes adressées au service d'API Vertex AI 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 Vertex AI Discovery Engine pour effectuer des appels à l'URL stable run.app enregistrée à partir de la fiche de l'agent. Pour que le service Cloud Run de l'agent d'IA autorise ces appels, vous devez accorder 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 sur 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 Vertex AI 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 renforcer la sécurité, nous vous recommandons que Gemini Enterprise appelle un agent A2A hébergé par 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 et 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 depuis des agents racine personnalisés vers des sous-agents et des 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 pour vos agents et outils conteneurisés sont Vertex AI Agent Engine, Cloud Run et GKE.

Lorsque vous choisissez une plate-forme d'hébergement d'agent, vous devez tenir compte des modèles de réseau privé, 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 savoir comment sélectionner une plate-forme d'hébergement d'agents d'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 agentique.

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

  • Agents personnalisés sur Vertex AI Agent Engine : les interfaces Private Service Connect connectent les runtimes Vertex AI Agent Engine au réseau VPC. Vous créez un rattachement réseau dans un sous-réseau de votre réseau VPC et accordez à Vertex AI Agent Engine l'autorisation de s'y rattacher. Le trafic envoyé depuis Vertex AI Agent Engine 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 de 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 local. 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 dans et hors du réseau VPC pour chaque plate-forme d'hébergement d'agents. Les considérations relatives au réseau s'appliquent à la fois à la fonctionnalité d'agent racine et à celle de sous-agent.

Mise en réseau Vertex AI Agent Engine

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

Vertex AI Agent Engine 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 Vertex AI Agent Engine vers le réseau VPC

Vertex AI Agent Engine utilise un projet locataire géré par Google pour la sortie réseau. Le réseau locataire permet aux agents de se connecter aux API Google et d'accéder à Internet public, mais il n'est pas directement connecté aux réseaux VPC des clients.

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

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

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

Trafic d'entrée Vertex AI Agent Engine depuis le réseau VPC

Les requêtes envoyées aux agents exécutés sur Vertex AI Agent Engine sont effectuées à l'aide du point de terminaison de l'API Vertex AI (aiplatform.googleapis.com). Pour accéder aux points de terminaison des API Google à l'aide de chemins 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 interrogent des agents doivent résoudre le nom d'hôte du point de terminaison de l'API Vertex AI en plage d'adresses IP privées pour l' accès privé à Google ou en adresse IP du point de terminaison Private Service Connect pour les API Google. Une zone Cloud DNS privée et gérée pour googleapis.com résout les requêtes pour l'API Vertex AI. 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 contribuer à protéger le trafic de votre réseau VPC vers Vertex AI Agent Engine en utilisant les produits et fonctionnalités suivants :

Autres considérations concernant le réseau Vertex AI Agent Engine

Le trafic sortant de Vertex AI Agent Engine qui utilise des interfaces Private Service Connect ne peut être acheminé que vers des plages d'adresses IP RFC 1918 dans le réseau VPC. Pour connaître les plages de destinations spécifiques qui ne peuvent pas être routées par la sortie Vertex AI Agent Engine, consultez Exigences concernant les plages d'adresses IP de sous-réseau. Pour atteindre des destinations de plage 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 Vertex AI Agent Engine 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 Vertex AI Agent Engine est déployé avec une interface Private Service Connect, la sortie Internet directe est désactivée, quels que soient les VPC Service Controls. Si vous avez besoin que votre agent accède à une destination que Vertex AI Agent Engine ne peut pas atteindre normalement, 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 de 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 Vertex AI Agent Engine afin de permettre la résolution des requêtes DNS de l'agent vers l'adresse privée du 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 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 de sortie de Vertex AI Agent Engine 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 Vertex AI Agent Engine, 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 à 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 sur le réseau interne de Google.

Toutes les requêtes DNS provenant de Cloud Run utilisent la stratégie 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 DNS privées Cloud DNS et les noms d'hôte publics.

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 depuis le réseau VPC

Cloud Run est une plate-forme gérée par Google qui fonctionne dans un environnement en dehors du 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'agents ou d'outils d'IA. Ces points de terminaison sont fournis par le même point d'entrée GFE que celui qui fournit 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 interrogent des agents ou des outils doivent résoudre le nom d'hôte run.app dans la plage d'adresses IP privées pour l'accès privé à Google ou dans 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.

Si vous définissez l'entrée Cloud Run sur Interne, l'accès à votre service est limité aux requêtes provenant de sources internes validées. Voici quelques exemples de sources approuvées :

  • 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 qui se trouvent dans le même périmètre VPC Service Controls.
  • Équilibreurs de charge d'application internes dans le réseau VPC.
  • Les 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 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. Ce trafic inclut le trafic provenant d'autres services Google Cloud, tels que Vertex AI Agent Engine et d'autres services Cloud Run. Pour satisfaire la vérification de l'entrée interne de Cloud Run, ce trafic doit être acheminé de manière à ce qu'il semble provenir du réseau VPC du service cible.

Pour fournir l'attribution nécessaire au réseau interne, vous pouvez procéder de l'une des deux manières 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 dans 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 provenant d'autres services via le réseau VPC afin qu'elles répondent aux critères d'entrée internes.

Les équilibreurs de charge d'application internes avec des backends de groupes de points de terminaison du réseau (NEG) sans serveur créent une ressource VPC qui est directement mappée à un service Cloud Run. Dans ce modèle, l'équilibreur de charge met fin aux connexions TLS du client 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 les 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'attribuer le rôle IAM Demandeur Cloud Run (roles/run.invoker) au principal.

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 contribuer à 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 contribuer à 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 outils et agents d'IA, 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 importantes.

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 sortant de Gemini Enterprise transite par le réseau Google Edge, où il emprunte un itinéraire optimisé vers l'équilibreur de charge externe GKE.

Il est important de sécuriser le point de terminaison GKE à l'aide d'une authentification et d'une autorisation fortes, de Cloud Armor et d'autorisations limitées. Pour fournir un modèle de défense en profondeur complet permettant de sécuriser les agents d'IA exécutés 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 du 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 restez entièrement responsable des configurations de pool de nœuds, comme la sélection des types de machines, la gestion des images d'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 principaux : limitez l'accès administratif à l'API Kubernetes à des plages d'adresses IP spécifiques et fiables, 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 gardien 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 permet de déplacer efficacement le périmètre de sécurité du réseau vers l'utilisateur individuel et le contexte de son appareil.
Protection des bordures et gestion du trafic
  • Cloud Armor : fournit une sécurité de périphérie robuste, y compris des règles de pare-feu d'application Web (WAF) pour bloquer les charges utiles malveillantes, une protection DDoS pour garantir la disponibilité 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 assainit les requêtes et les réponses en temps réel pour empêcher l'injection de requêtes et l'exfiltration de données.
Isolation du réseau interne
  • Règles de réseau Kubernetes : appliquent une communication précise et à privilège minimum entre les microservices. Par défaut, les règles refusent tout le trafic, sauf si vous l'autorisez explicitement. Cela empêche les déplacements latéraux dans le 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 de réseau de cluster GKE par défaut est VPC natif, qui présente 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 d'agent de destination se trouve sur un nœud différent 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 en utilisant les produits et services suivants :

Trafic d'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-agents, nous vous recommandons d'utiliser une passerelle GKE ou une passerelle GKE Inference. La passerelle offre des fonctionnalités améliorées de contrôle du trafic, de séparation opérationnelle des ressources et d'intégration de la 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 câblé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 outils et agents d'IA hébergés sur des clusters GKE :

  • Cloud Armor : protège les services en associant une règle de sécurité Cloud Armor aux services de backend gérés par la passerelle. Il fournit un filtrage WAF, un filtrage basé sur les adresses 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 des identifiants IAM, IAP applique des stratégies d'accès Zero Trust. IAP authentifie et autorise les agents d'IA qui accèdent aux ressources du cluster, y compris les applications Gemini Enterprise, les agents personnalisés et les ressources externes. Il exige que les appelants disposent d'une identité authentifiée par IAM et d'une autorisation pour accéder au service de backend.

Si vous envoyez du trafic de votre réseau VPC vers votre service GKE via une passerelle, vous pouvez contribuer à protéger ce trafic en utilisant les 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 contribuer à protéger ce trafic en utilisant les 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é du réseau de l'agent

Pour protéger le réseau d'un système d'IA multi-agents, 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 explique comment 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é très contrôlée et résiliente.

Cloud NGFW

Cloud NGFW fait office de 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 de 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 les adresses 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 : offre de véritables fonctionnalités d'inspection des applications (couche 7) 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 de l'agent que vous avez utilisée.

  • Vertex AI Agent Engine : les agents qui s'exécutent dans Vertex AI Agent Engine se connectent au réseau VPC à l'aide de rattachements de réseau Private Service Connect. Ces rattachements permettent à l'interface réseau de l'agent d'apparaître dans un sous-réseau du réseau VPC. Les stratégies de pare-feu 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 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 règles de pare-feu 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 de destination.
  • GKE : les clusters GKE natifs VPC 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 également utiliser des tags sécurisés et des comptes de service. Les tags sécurisés sont associés aux instances de VM qui servent de nœuds GKE. Les règles de pare-feu peuvent ensuite cibler ou générer du trafic à partir de nœuds associés à des tags spécifiques. Les règles de pare-feu peuvent également cibler ou générer du trafic à partir de nœuds GKE en fonction de l'identité du compte de service associé au pool de nœuds.

Règle de sortie de refus par défaut

L'implémentation 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 autorisé, tandis que tout autre trafic est bloqué par défaut. Cette implémentation est obtenue en structurant les règles de pare-feu avec des règles ALLOW de haute priorité pour les flux légitimes connus et une règle DENY de faible priorité pour tous les autres flux. 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 l'attachement réseau Vertex AI Agent Engine et du sous-réseau de sortie VPC directe Cloud Run.

Voici un exemple de règle de sortie 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, puis 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 nombres de priorité plus faibles, par exemple de 100 à 1 000. Ces règles autorisent précisément le trafic réseau nécessaire au fonctionnement de vos agents d'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 correspond au trafic source du sous-réseau de l'association de réseau Vertex AI Agent Engine ou du sous-réseau de sortie VPC directe Cloud Run vers les destinations de votre choix.
  • Règle générale DENY : 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 sortie de refus par défaut empêche les agents d'IA d'établir des connexions réseau qui ne sont pas explicitement autorisées. Elle bloque également l'exfiltration potentielle de données ou l'accès à des sites malveillants. Cette règle limite la communication des agents hébergés aux points de terminaison approuvés uniquement, ce qui est essentiel pour garder le contrôle sur les charges de travail autonomes.

Autres points à prendre en compte concernant les règles Cloud NGFW

En plus de la stratégie de refus par défaut disponible avec tous les niveaux Cloud NGFW, vous pouvez renforcer davantage la sécurité de votre réseau d'IA multi-agents en utilisant les fonctionnalités des niveaux payants :

  • Fonctionnalités de Cloud NGFW Standard :
    • Objets FQDN pour les points de terminaison dynamiques : les agents d'IA interagissent souvent avec des API externes, des points de terminaison de modèles 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 d'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 zones.
    • 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 les serveurs de commande et de contrôle (C2), les anonymiseurs comme Tor et les 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 dont le numéro de priorité est plus élevé (ordre d'évaluation plus faible).
  • Fonctionnalités Cloud NGFW Enterprise :
    • Inspection de la 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 failles qui ne sont pas analysées par les règles de pare-feu de la couche réseau.
    • Inspection TLS : activez l'inspection TLS pour permettre au moteur d'inspection d'analyser le trafic chiffré. L'inspection TLS est essentielle, car la plupart des attaques modernes et des communications C2 sont chiffrées.

Pour connaître les autres considérations ou limites d'implémentation pouvant 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 et vérifie l'identité et les autorisations de l'appelant. IAP permet uniquement aux requêtes authentifiées et autorisées de passer à la charge de travail du service de backend. IAP sur l'équilibreur de charge de 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é comme 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 "Utilisateur de l'application Web sécurisée par IAP" qu'aux comptes de service des agents autorisés à accéder à d'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 macropérimètre incluant tous les services compatibles. Cette approche offre la protection la plus efficace contre l'exfiltration. Pour garantir une application cohérente des règles pour les architectures 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 d'autorisation. 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 remplies :
    • VPC Service Controls n'est pas activé.
    • Cloud Run et Gemini Enterprise ne se trouvent pas dans le même projet.
  • Seul l'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 d'implémenter les consignes suivantes pour vous assurer d'une protection complète :

  • Restreindre 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. Il est possible que les déploiements précédents ne soient pas 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 de 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 précédents ne soient pas 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.
  • Colocalisez les images de conteneurs et les services : le dépôt Artifact Registry contenant 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 les identités de compte principal IAM ne sont pas compatibles avec les appels Cloud Run. Vous devez plutôt gérer l'accès avec des critères basés sur le réseau ou des niveaux d'accès basés sur les appareils.

Model Armor

Model Armor est un service basé sur une API qui renforce la sécurité des applications d'IA. Les agents d'IA interagissent avec Model Armor en effectuant des appels pour nettoyer les requêtes utilisateur avant qu'elles ne soient envoyées à un LLM, et pour nettoyer les réponses du modèle avant qu'elles ne soient renvoyées à l'utilisateur. Model Armor analyse activement les requêtes et les réponses des LLM, ce qui constitue un point d'inspection important pour détecter les risques émergents et un point de contrôle pour implémenter 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 juridiques 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 auquel vous accédez 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 contribuent à assurer la résidence des données.

Pour activer l'accès des agents, configurez les composants suivants dans chaque région où le service Model Armor est requis :

  1. Créez ou identifiez un sous-réseau RFC 1918 dans la région du réseau VPC où réside 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 DNS privée Cloud 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 est résolu en adresse IP du point de terminaison régional.
  4. Pour l'interopérabilité de Vertex AI Agent Engine, établissez un appairage DNS de Vertex AI Agent Engine à 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 en 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 runtimes des service de backend. Les charges de travail des agents d'IA impliquent de gros volumes de communication entre les services à l'aide d'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 agentiques attendues. En associant des règles de sécurité Cloud Armor aux services de backend de l'équilibreur de charge d'application, le trafic peut être filtré pour détecter les requêtes malveillantes et contrôlé avec des limites de débit. Les attaques DDoS peuvent également être atténuées.

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 limiter le 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.
  • Gateway : 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 est compatible avec les règles de sécurité de backend avec des règles WAF, des contrôles basés sur les adresses IP et la géolocalisation, et la 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é de périphérie supplémentaires avec Google Cloud Armor Adaptive Protection et Google Threat Intelligence.

Proxy Web sécurisé

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 sert de point d'application centralisé pour le proxy et la sécurité afin de fournir un contrôle précis et une visibilité sur le trafic Internet sortant. Il sert également de proxy explicite pour les communications de service internes.

Secure Web Proxy est compatible avec trois modes de déploiement : le mode de routage de proxy explicite, le mode de rattachement de service Private Service Connect et le mode de prochain saut. Nous vous recommandons d'utiliser le proxy Web sécurisé en mode de routage de proxy explicite, qui est le sujet 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 Secure Web Proxy.

Pour déployer Secure Web Proxy dans votre réseau VPC, vous devez configurer un sous-réseau de frontend et un sous-réseau proxy réservé. Secure Web Proxy est un service entièrement géré. Lorsque le proxy Web sécurisé 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 transitent par Secure Web Proxy avant d'être envoyées sur Internet.

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

Routage explicite du proxy

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

Pour permettre aux plates-formes 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 est résolu en adresse IP de la ressource de proxy Web sécurisé.
  3. Pour l'interopérabilité de Vertex AI Agent Engine, établissez un appairage DNS de Vertex AI Agent Engine à la zone privée Cloud DNS associée à votre réseau VPC. Lorsque les agents envoient des requêtes au proxy Web sécurisé, Cloud DNS résout les requêtes de nom d'hôte en adresse IP de la ressource de proxy Web sécurisé 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 au 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 ajouter 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 Service d'autorité de certification.
  • 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 aux 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 le proxy Web sécurisé 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 Vertex AI Agent Engine à 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 lorsque les instances de service démarrent.

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

Le service d'autorité de certification (CA Service) est requis lorsque le proxy Web sécurisé 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, le service CA crée et signe un certificat pour cette destination. Lorsque le trafic chiffré pour la destination réelle arrive au niveau du proxy Web sécurisé ou de Cloud NGFW, le paquet est déchiffré et inspecté, puis les règles sont appliquées. 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.

Le service d'autorité de certification est un service géré. Une fois le service d'autorité de certification configuré, il gère la signature des certificats d'entité finale jusqu'à l'expiration du certificat d'autorité de certification racine. Les certificats d'autorité de certification racine doivent être mis à jour pour ne pas expirer.

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

  • Inspection TLS : l'utilisation d'une autorité de certification privée est requise pour l'inspection TLS complète. Pour déchiffrer et analyser complètement les charges utiles HTTPS, le périphérique 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'usurpation d'identité spécifique au site demandé. Lorsque le certificat CA 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 et 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 d'IA qui s'exécutent sur Vertex AI Agent Engine, Cloud Run ou GKE nécessitent l'ajout du certificat CA racine privé à leurs magasins de confiance locaux. En stockant la clé publique du certificat de l'autorité de certification racine dans Secret Manager, les agents d'IA peuvent extraire le certificat au démarrage et l'ajouter à leur magasin de confiance système.

    Les ressources de serveur internes, comme les équilibreurs de charge d'application internes, ont besoin de certificats émis par l'autorité de certification privée pour servir de points de terminaison de serveur fiables et mettre fin aux sessions TLS des clients. Les équilibreurs de charge d'application s'intègrent aux configurations d'émission du gestionnaire de certificats 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 présente des exigences uniques en matière de réseau et de sécurité qui doivent être abstraites 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 :

Schémas de connectivité Agent2Agent (A2A) entre différentes plates-formes d'hébergement, y compris GKE, Cloud Run et Vertex AI Agent Engine, 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 Vertex AI Agent Engine.
  • L'application Gemini Enterprise et les agents racine utilisent l'infrastructure Google pour se connecter à Model Armor et au LLM Gemini sur Vertex AI.
  • Les agents racine peuvent utiliser l'infrastructure Google pour se connecter aux sous-agents qui s'exécutent dans Cloud Run ou Vertex AI Agent Engine.
  • Les agents racine peuvent utiliser des adresses IP privées pour se connecter aux sous-agents qui s'exécutent dans Vertex AI Agent Engine, 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 transite par le réseau VPC qui héberge le cluster GKE.

Agent de destination (chemin de données) Contrôle de sécurité
Vertex AI Agent Engine (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 Vertex AI Agent Engine (interne)

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

Agent de destination (chemin de données) Contrôle de sécurité
Vertex AI Agent Engine (interne)
Cloud Run (interne)

Agent source Vertex AI Agent Engine (interface Private Service Connect)

Le tableau suivant fournit des ressources pour vous aider à protéger le trafic lorsque Vertex AI Agent Engine 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 de 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 d'accès, aucun réseau VPC n'est impliqué.

Agent de destination (chemin de données) Contrôle de sécurité
Vertex AI Agent Engine (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 de 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
Vertex AI Agent Engine Private Service Connect 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 de données entre les environnements d'exécution de l'agent et les serveurs MCP. Pour les agents sources dans Vertex AI Agent Engine, 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
    • Proxy Web sécurisé
  • 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 :