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 de réseau privé 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 Agent Runtime sur la plate-forme Gemini Enterprise Agent, 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 MCP (Model Context Protocol). 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 maîtrisez les concepts de mise en réseau de 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 aux 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 les tâches spécialisées aux 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 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 différentes options pour connecter les agents racine aux sous-agents et aux outils 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 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 accessibilité 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 aux outils et interagissent avec eux 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, 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 aux applications.

Le VPC partagé impose 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 Cross-Cloud Network 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, des 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.
  • Google APIs 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 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 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 Agent Runtime 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 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 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 la section 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 de Gemini Enterprise Agent Platform. 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 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 de l'Agent Platform 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 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 renforcer la sécurité, nous vous recommandons que Gemini Enterprise appelle un agent A2A hébergé dans 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 lancées à partir d'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 de vos agents et outils conteneurisés sont Agent Runtime, 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 d'agent que vous utilisez :

  • Agents personnalisés sur Agent Runtime : les interfaces Private Service Connect connectent les runtimes 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 accordez à Agent Runtime l'autorisation de 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 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 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.

L'environnement d'exécution de l'agent 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 Agent Runtime vers le réseau VPC

L'environnement d'exécution de l'agent 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 par défaut.

Pour connecter des agents à des ressources qui se trouvent 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 network attachment 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 de l'environnement d'exécution de l'agent, consultez les sections suivantes de ce document :

Trafic d'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 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 Agent Platform 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 privée géré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 de votre réseau VPC vers Agent Runtime à l'aide des produits et fonctionnalités suivants :

Autres points à prendre en compte concernant le réseau Agent Runtime

La sortie d'exécution de l'agent qui utilise des interfaces Private Service Connect ne peut être acheminée 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 Agent Runtime, consultez Exigences concernant la plage d'adresses IP du 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 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 Agent Runtime 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 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 de proxy explicite.
  2. Créez un enregistrement Cloud DNS pour le nom d'hôte du proxy Web sécurisé.
  3. Configurez le peering DNS pour Agent Runtime 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 sortant 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 à 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 achemine 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 règle et les zones Cloud DNS associées au réseau VPC. Aucune configuration supplémentaire du peering DNS n'est requise. Les agents hébergés sur Cloud Run résolvent toutes les zones 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 IA ou d'outils. 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é, car seules les requêtes provenant de sources internes vérifiées sont autorisé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 qu'Agent Runtime 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 de réseau interne nécessaire, 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, en utilisant 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 interne.

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 en utilisant les 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. 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 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 de périphérie 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 assurer 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 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 : appliquent une communication précise et à privilèges minimum entre les microservices. Par défaut, les règles refusent tout le trafic, sauf si vous l'autorisez explicitement, ce qui empêche les mouvements 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 GKE Inference Gateway. 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é hautement contrôlée et résiliente.

Cloud NGFW

Cloud NGFW fait office de contrôleur d'accès 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 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.

Vous pouvez appliquer Cloud NGFW 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.

  • Environnement d'exécution de l'agent : les agents qui s'exécutent dans l'environnement d'exécution de l'agent se connectent au réseau VPC à l'aide de rattachements de réseau Private Service Connect. Ces associations 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 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 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 de destination.
  • GKE : les clusters GKE natifs au 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 de 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'association réseau Agent Runtime 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 de 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, équilibreurs de charge, API Google requises ou points de terminaison externes légitimes. Créez une règle qui correspond au trafic source provenant du sous-réseau de l'association de réseau Agent Runtime ou du sous-réseau de sortie VPC directe Cloud Run vers les destinations souhaitées.
  • 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, ce qui est essentiel pour garder le contrôle sur les charges de travail autonomes.

Autres considérations 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 standards de Cloud NGFW :
    • 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 de nom de domaine complet 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 exploits qui ne sont pas analysés 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 n'autorise que les requêtes authentifiées et autorisées à 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 laisse le service exposé à l'Internet public.

  • L'entrée Cloud Run all est prise en charge 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 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 appelant des fonctions 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 examine 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 permettent d'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 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 est résolu en 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 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 des volumes élevés 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, vous pouvez filtrer le trafic pour détecter les requêtes malveillantes et le contrôler avec 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 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.
  • 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 mondial 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.

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 sert de point d'application de la sécurité et de proxy centralisé pour 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 saut suivant. Nous vous recommandons d'utiliser Secure Web Proxy en mode de routage de 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 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 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 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 Agent Runtime Private Service Connect, de la sortie VPC directe Cloud Run et des clusters GKE natifs au VPC. Lorsque les agents envoient des requêtes à 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é, Secure Web Proxy 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 Agent Runtime 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é 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 dans le 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 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 à 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 est résolu en 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 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 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 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 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, le service d'autorité de certification crée et signe un certificat pour cette destination. Lorsque le trafic chiffré pour la destination réelle arrive au niveau de Secure Web Proxy 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 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 récupérer 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 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 présente des exigences uniques en matière de mise en 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 qui sont 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 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 le proxy Web sécurisé.

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é
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 de 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 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é
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 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
Agent Runtime 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 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 :