Déployer Secure Web Proxy en tant qu'Agent Gateway

Aperçu

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette page explique comment configurer et déployer votre instance Secure Web Proxy en tant qu'Agent Gateway.

Présentation

Les charges de travail d'IA d'entreprise déployées sur Google Cloud nécessitent des limites de réseau structurées pour maintenir la conformité avec la confidentialité des données, éviter les fuites de données sensibles et se protéger contre les nouvelles menaces liées à l'IA, telles que l'injection de prompt.

Agent Gateway fournit une gouvernance de sécurité centralisée, l'application de l'identité et des garde-fous de contenu pour le trafic sortant des agents IA vers les grands modèles de langage (LLM), les outils Model Context Protocol (MCP), les API externes, les agents distants et les destinations Web standards.

Vous pouvez déployer une instance Agent Gateway gérée par Google ou une instance Secure Web Proxy en tant qu'Agent Gateway autogéré. Les deux modèles de déploiement fournissent une solution de gouvernance Gemini Enterprise Agent Platform commune, y compris des règles d'accès centralisées, l'intégration d'Agent Registry et des garde-fous de contenu.

Choisissez l'une des options de déploiement suivantes en fonction de vos préférences opérationnelles :

• Agent Gateway géré par Google : utilisez cette option si vous souhaitez une expérience entièrement gérée, sans maintenance, sans avoir à gérer l'infrastructure de proxy réseau. Pour en savoir plus, consultez Agent Gateway géré par Google. Ce modèle est optimisé pour les agents qui s'exécutent sur Gemini Enterprise ou Agent Runtime sur Gemini Enterprise Agent Platform.

• Secure Web Proxy en tant qu'Agent Gateway autogéré : déployez votre instance Secure Web Proxy en tant qu'Agent Gateway si vous souhaitez conserver un contrôle total sur le périmètre de votre réseau VPC, les certificats CA privés et le routage proxy pour prendre en charge les agents qui s'exécutent sur Google Kubernetes Engine (GKE) ou Cloud Run.

Avantages

Le déploiement de Secure Web Proxy en tant qu'Agent Gateway offre les avantages suivants :

• Infrastructure contrôlée par le client : vous pouvez gérer la passerelle Secure Web Proxy dans votre propre réseau cloud privé virtuel (VPC), en conservant un contrôle total sur le routage réseau, l'adressage IP, les certificats CA privés et l'inspection TLS.

• Application centralisée des règles d'IA : vous pouvez définir des stratégies d'autorisation sur une ressource agentGateway. Cela vous permet d'appliquer directement ces règles sur votre passerelle Secure Web Proxy pour limiter les appels d'outils MCP, filtrer les destinations externes des agents IA et appeler des services de nettoyage de contenu comme Model Armor.

• Compatibilité avec les environnements d'exécution : vous pouvez acheminer le trafic sortant des agents IA hébergés dans différents environnements d'exécution, tels que GKE ou Cloud Run, via un seul périmètre de proxy.

• Observabilité basée sur les agents : les journaux de transactions dans Cloud Logging contiennent automatiquement les métadonnées d'exécution de l'agent IA (agentGatewayInfo), y compris les méthodes MCP, les noms des outils et les noms de ressources uniformes (URN) des destinations Agent Registry.

Architecture

Les étapes suivantes montrent comment Secure Web Proxy sécurise le trafic sortant en tant qu'Agent Gateway :

1. Environnements d'exécution d'agent : les agents autonomes qui s'exécutent sur GKE ou Cloud Run lancent des connexions sortantes vers des API externes, des fournisseurs de modèles, des serveurs d'outils MCP, des agents distants ou des destinations Web standards.

2. Routage du trafic sortant : le trafic de l'agent est dirigé vers Secure Web Proxy à l'aide du routage proxy dans le VPC ou des rattachements de service Private Service Connect (PSC) entre VPC.

3. Évaluation des règles et nettoyage du contenu : Secure Web Proxy met fin aux connexions TLS, applique les règles d'autorisation MCP et appelle des services d'extension tels que Model Armor ou Identity-Aware Proxy (IAP) pour nettoyer les charges utiles et vérifier l'identité du client.

Avant de commencer

Avant de déployer votre instance Secure Web Proxy en tant qu'Agent Gateway, remplissez les conditions préalables suivantes :

1. Activez les API Google Cloud requises suivantes :

   gcloud services enable \
       networkservices.googleapis.com \
       networksecurity.googleapis.com \
       privateca.googleapis.com \
       certificatemanager.googleapis.com \
       serviceextensions.googleapis.com \
       agentregistry.googleapis.com \
       compute.googleapis.com
   

2. Assurez-vous de disposer des rôles IAM (Identity and Access Management) requis suivants :

   • Rôle Administrateur de réseaux Compute (roles/compute.networkAdmin)
   • Rôle Administrateur de la sécurité du réseau (roles/networksecurity.admin)
   • Rôle Administrateur de CA Service (roles/privateca.admin)

3. Configurez les variables d'environnement suivantes pour votre déploiement :

   export PROJECT_ID="my-project-id"
   export PROJECT_NUMBER="my-project-number"
   export REGION="us-central1"
   export NETWORK_NAME="swp-vpc"
   export PROXY_SUBNET_NAME="swp-proxy-subnet"
   export PSC_NAT_SUBNET_NAME="swp-psc-nat-subnet"
   export CA_POOL_NAME="swp-ca-pool"
   export ROOT_CA_NAME="swp-root-ca"
   export TLS_INSPECTION_POLICY_NAME="swp-tls-inspection-policy"
   export SECURE_WEB_PROXY_NAME="swp-agent-gateway"
   export SWP_IP_ADDRESS="10.129.0.10"
   export SWP_CERTIFICATE_NAME="swp-cert"
   export SERVER_TLS_POLICY_NAME="swp-server-tls-policy"
   export GATEWAY_SECURITY_POLICY_NAME="swp-security-policy"
   export SERVICE_ATTACHMENT_NAME="swp-service-attachment"
   export AGENT_GATEWAY_NAME="my-agent-gateway"
   

4. Facultatif : Si vos environnements d'exécution d'agent fonctionnent dans des réseaux VPC ou des environnements gérés distincts, tels que des clusters GKE ou Cloud Run interprojets, vous devez exposer Secure Web Proxy via un rattachement de service Private Service Connect :

   • Créez un sous-réseau NAT PSC avec --purpose=PRIVATE_SERVICE_CONNECT.
   • Créez un rattachement de service qui cible votre passerelle Secure Web Proxy. Pour en savoir plus, consultez Déployer Secure Web Proxy en tant que service Private Service Connect.

Configurer l'inspection TLS

Secure Web Proxy met fin aux connexions TLS pour inspecter les en-têtes HTTP, évaluer les méthodes MCP et nettoyer les charges utiles.

Pour configurer l'inspection TLS, créez un pool d'autorités de certification (CA) privées, une CA racine, puis une ressource tlsInspectionPolicy en procédant comme suit :

1. Créer un pool d'autorités de certification privées.

   gcloud privateca pools create CA_POOL_NAME \
       --location=REGION \
       --tier=devops \
       --project=PROJECT_ID
   

   Remplacez les éléments suivants :

   • CA_POOL_NAME : nom du pool d'autorités de certification
   • REGION : région dans laquelle le pool d'autorités de certification est créé
   • PROJECT_ID : ID de votre projet Google Cloud

2. Créez une autorité de certification racine dans le pool d'autorités de certification privées.

   gcloud privateca roots create ROOT_CA_NAME \
       --pool=CA_POOL_NAME \
       --location=REGION \
       --subject="CN=Agent Gateway SWP Root CA, O=MyOrganization" \
       --auto-enable \
       --project=PROJECT_ID
   

   Remplacez les éléments suivants :

   • ROOT_CA_NAME : nom de l'autorité de certification racine
   • CA_POOL_NAME : nom du pool d'autorités de certification
   • REGION : région où l'autorité de certification racine est créée
   • PROJECT_ID : ID de votre projet Google Cloud

   Remarque : Pour permettre aux charges de travail clientes, telles que Cloud Run ou GKE, de faire confiance aux certificats émis par ce pool d'autorités de certification lors de l'inspection TLS, exportez le certificat CA racine, puis ajoutez-le au magasin de confiance de votre charge de travail. Par exemple, vous pouvez définir la variable d'environnement AGENT_GATEWAY_ROOT_CERTIFICATES.

3. Accordez au compte de service Sécurité réseau l'autorisation de demander des certificats.

   gcloud privateca pools add-iam-policy-binding CA_POOL_NAME \
       --location=REGION \
       --member="serviceAccount:[e-mail]" \
       --role="roles/privateca.certificateRequester" \
       --project=PROJECT_ID
   

4. Créez la ressource tlsInspectionPolicy dans un fichier nommé tls-inspection-policy.yaml.

   name: projects/PROJECT_ID/locations/REGION/tlsInspectionPolicies/TLS_INSPECTION_POLICY_NAME
   caPool: projects/PROJECT_ID/locations/REGION/caPools/CA_POOL_NAME
   

   Remplacez les éléments suivants :

   • PROJECT_ID : ID de votre projet Google Cloud
   • REGION : région dans laquelle TlsInspectionPolicy est créé
   • TLS_INSPECTION_POLICY_NAME : nom de la ressource TlsInspectionPolicy.
   • CA_POOL_NAME : nom du pool d'autorités de certification

5. Pour importer la stratégie, exécutez la commande gcloud network-security tls-inspection-policies import.

   gcloud network-security tls-inspection-policies import TLS_INSPECTION_POLICY_NAME \
       --source=tls-inspection-policy.yaml \
       --location=REGION \
       --project=PROJECT_ID
   

Déployer Secure Web Proxy

Créez une passerelle Secure Web Proxy avec TLS mutuelle (mTLS) configurée.

1. Assurez-vous que votre réseau VPC dispose d'un sous-réseau proxy réservé dans la région où vous souhaitez déployer la passerelle.

   gcloud compute networks subnets create PROXY_SUBNET_NAME \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=REGION \
       --network=NETWORK_NAME \
       --range=10.129.0.0/23
   

   Remplacez les éléments suivants :

   • PROXY_SUBNET_NAME : nom du sous-réseau proxy réservé
   • NETWORK_NAME : nom de votre réseau VPC
   • REGION : région où le sous-réseau est créé

2. Facultatif : Sélectionnez une adresse IP disponible dans la plage de votre sous-réseau proxy réservé (par exemple, 10.129.0.10 dans 10.129.0.0/23) à attribuer à votre SWP_IP_ADDRESS.

   Remarque : Si vous n'ajoutez pas le champ addresses dans le fichier swp.yaml, Secure Web Proxy alloue automatiquement une adresse IP à partir du sous-réseau proxy réservé.

3. Pour vous assurer que votre passerelle Secure Web Proxy peut accepter de manière sécurisée les connexions d'agents clients entrants, créez un certificat de serveur SSL/TLS régional dans Certificate Manager.

   1. Générez un certificat autogéré et une clé privée.

      openssl req -x509 -newkey rsa:2048 -nodes \
          -keyout "swp.key" \
          -out "swp.crt" \
          -days 365 \
          -subj "/CN=SWP_IP_ADDRESS"
      

      Remplacez SWP_IP_ADDRESS par l'adresse IP de votre passerelle Secure Web Proxy.

   2. Pour importer le certificat dans Certificate Manager, exécutez la commande gcloud certificate-manager certificates create.

      gcloud certificate-manager certificates create SWP_CERTIFICATE_NAME \
          --location=REGION \
          --certificate-file="swp.crt" \
          --private-key-file="swp.key" \
          --project=PROJECT_ID
      

      Remplacez les éléments suivants :

      • SWP_CERTIFICATE_NAME : nom de la ressource de certificat
      • REGION : région dans laquelle le certificat est créé.
      • PROJECT_ID : ID de votre projet Google Cloud

4. Pour activer mTLS sur l'interface, créez une ressource ServerTlsPolicy. Pour permettre aux charges de travail, telles que Cloud Run, de transmettre leurs certificats d'identité à des services comme IAP, configurez la règle avec clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

   Remarque : Si vous utilisez IAP, ne définissez aucune valeur pour le champ clientValidationTrustConfig, car il n'est pas accepté.

   1. Créez un fichier nommé server-tls-policy.yaml, puis ajoutez le contenu suivant :

      name: projects/PROJECT_ID/locations/REGION/serverTlsPolicies/SERVER_TLS_POLICY_NAME
      mtlsPolicy:
        clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
      

      Remplacez les éléments suivants :

      • PROJECT_ID : ID de votre projet Google Cloud
      • REGION : région dans laquelle ServerTlsPolicy est créé
      • SERVER_TLS_POLICY_NAME : nom de la ressource ServerTlsPolicy.

   2. Pour importer la stratégie, exécutez la commande gcloud network-security server-tls-policies import.

      gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
          --source=server-tls-policy.yaml \
          --location=REGION \
          --project=PROJECT_ID
      

5. Créez une stratégie de sécurité de passerelle pour associer votre tlsInspectionPolicy.

   1. Créez un fichier nommé gateway-security-policy.yaml, puis ajoutez le contenu suivant :

      name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/GATEWAY_SECURITY_POLICY_NAME
      tlsInspectionPolicy: projects/PROJECT_ID/locations/REGION/tlsInspectionPolicies/TLS_INSPECTION_POLICY_NAME
      

      Remplacez les éléments suivants :

      • PROJECT_ID : ID de votre projet Google Cloud
      • REGION : région dans laquelle GatewaySecurityPolicy est créé
      • GATEWAY_SECURITY_POLICY_NAME : nom de la ressource GatewaySecurityPolicy.
      • TLS_INSPECTION_POLICY_NAME : nom de la ressource TlsInspectionPolicy.

   2. Pour importer la stratégie, exécutez la commande gcloud network-security gateway-security-policies import.

      gcloud network-security gateway-security-policies import GATEWAY_SECURITY_POLICY_NAME \
          --source=gateway-security-policy.yaml \
          --location=REGION \
          --project=PROJECT_ID
      

6. Créez un fichier de spécification Secure Web Proxy nommé swp.yaml.

   name: projects/PROJECT_ID/locations/REGION/gateways/SECURE_WEB_PROXY_NAME
   type: SECURE_WEB_GATEWAY
   addresses:
     - "SWP_IP_ADDRESS"
   ports:
     - 443
   routingMode: EXPLICIT_ROUTING_MODE
   certificateUrls:
     - projects/PROJECT_ID/locations/REGION/certificates/SWP_CERTIFICATE_NAME
   serverTlsPolicy: projects/PROJECT_ID/locations/REGION/serverTlsPolicies/SERVER_TLS_POLICY_NAME
   network: projects/PROJECT_ID/global/networks/NETWORK_NAME
   subnetwork: projects/PROJECT_ID/regions/REGION/subnetworks/PROXY_SUBNET_NAME
   gatewaySecurityPolicy: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/GATEWAY_SECURITY_POLICY_NAME
   

   Remplacez les éléments suivants :

   • PROJECT_ID : ID de votre projet Google Cloud
   • REGION : région dans laquelle votre passerelle Secure Web Proxy est créée.
   • SECURE_WEB_PROXY_NAME : nom de votre passerelle Secure Web Proxy
   • SWP_IP_ADDRESS : adresse IP de votre passerelle Secure Web Proxy
   • SWP_CERTIFICATE_NAME : nom du certificat associé à votre passerelle Secure Web Proxy
   • SERVER_TLS_POLICY_NAME : nom de la ressource ServerTlsPolicy
   • NETWORK_NAME : nom de votre réseau VPC
   • PROXY_SUBNET_NAME : nom du sous-réseau proxy réservé
   • GATEWAY_SECURITY_POLICY_NAME : nom de la ressource GatewaySecurityPolicy.

7. Pour importer la passerelle Secure Web Proxy, exécutez la commande gcloud network-services gateways import.

   gcloud network-services gateways import SECURE_WEB_PROXY_NAME \
       --source=swp.yaml \
       --location=REGION \
       --project=PROJECT_ID
   

Remarque : Une fois que vous avez créé une passerelle Secure Web Proxy, vous ne pouvez plus modifier les champs addresses et ports. De plus, si vous mettez à jour le serverTlsPolicy ou le certificateUrls d'une passerelle existante, les modifications ne sont pas automatiquement propagées aux charges de travail, telles que Cloud Run, qui utilisent la ressource EgressRouting.

Pour modifier ces champs sur une passerelle Secure Web Proxy existante sans entraîner de temps d'arrêt de la charge de travail, procédez comme suit :

1. Créez une autre passerelle Secure Web Proxy avec un nouveau nom et la configuration requise.

2. Mettez à jour la ressource agentGateway (selfManaged.resourceUris) pour référencer la nouvelle passerelle Secure Web Proxy.

3. Mettez à jour votre ressource EgressRouting pour qu'elle pointe vers la nouvelle passerelle Secure Web Proxy.

4. Après avoir vérifié que la nouvelle passerelle gère correctement les routes de trafic, supprimez l'ancienne passerelle Secure Web Proxy de la ressource agentGateway, puis supprimez l'ancienne ressource de passerelle.

Associer votre instance Secure Web Proxy à une Agent Gateway

Remarque : Nous vous recommandons de déployer une passerelle Secure Web Proxy dédiée connectée à une passerelle Agent Gateway spécifiquement pour le trafic des agents IA, plutôt que de réutiliser un proxy configuré pour des charges de travail non agentives. Cette séparation permet de s'assurer que les garde-fous spécifiques aux agents, tels que les liaisons d'extension, le filtrage des méthodes MCP et la validation de l'identité du client, sont isolés des règles de sécurité de la passerelle standard.

Pour associer votre instance Secure Web Proxy à une ressource agentGateway, procédez comme suit :

1. Créez un fichier de configuration nommé agent-gateway.yaml.

   name: projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME
   selfManaged:
     resourceUris:
       - //networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/SECURE_WEB_PROXY_NAME
   registries:
     - //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION
   

   Remplacez les éléments suivants :

   • PROJECT_ID : ID de votre projet Google Cloud
   • REGION : région dans laquelle l'Agent Gateway est créé
   • AGENT_GATEWAY_NAME : nom de l'Agent Gateway.
   • SECURE_WEB_PROXY_NAME : nom de votre instance Secure Web Proxy

   Facultatif : le champ registries associe votre Agent Gateway à un Agent Registry. Si vous ne souhaitez pas utiliser Agent Registry pour la résolution de la destination ou de l'outil, ne spécifiez pas le champ registries.

2. Pour importer la ressource agentGateway, exécutez la commande gcloud beta network-services agent-gateways import.

   gcloud beta network-services agent-gateways import AGENT_GATEWAY_NAME \
       --source=agent-gateway.yaml \
       --location=REGION \
       --project=PROJECT_ID
   

Configurer les liaisons d'extension et les règles d'autorisation

Pour régir le trafic sortant des agents IA, configurez des liaisons d'extension et des règles d'autorisation sur votre ressource agentGateway. Le proxy ignore toutes les règles directement associées à la ressource Secure Web Proxy Gateway sous-jacente.

Agent Gateway est compatible avec les deux couches de gouvernance suivantes :

• Liaisons d'extensions : associez des services de sécurité et de gouvernance externes, tels qu'IAP et Model Armor, directement à votre Agent Gateway à l'aide de Service Extensions.

• Règles d'autorisation : appliquez des restrictions de méthode MCP L7 et des règles de réseau L4.

Associer des liaisons d'extension à Agent Gateway

Utilisez des liaisons d'extension dans Service Extensions pour lier des services gérés à votre Agent Gateway afin d'inspecter, d'authentifier et de contrôler les interactions des agents.

Étape 1 : Associez Identity-Aware Proxy (IAP) à votre Agent Gateway

Pour valider l'identité des appelants de l'agent et appliquer des règles d'accès avant que le trafic n'atteigne les outils cibles, associez IAP à votre Agent Gateway en procédant comme suit :

1. Créez un fichier de configuration nommé ext-binding-iap.yaml.

   name: ext-binding-iap
   target:
     resources:
     - "//networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME"
   failOpen: false
   producerExtension: iap.googleapis.com
   matchConditions:
   - to:
       destination:
         resources:
         - prefix: "urn:mcp"
       notDestinations:
         hosts:
         - suffix: ".googleapis.com"
   

   Remplacez les éléments suivants :

   • PROJECT_ID : ID de votre projet Google Cloud
   • REGION : région dans laquelle la liaison d'extension est créée
   • AGENT_GATEWAY_NAME : nom de l'Agent Gateway.

2. Pour importer la liaison d'extension, exécutez la commande gcloud beta service-extensions extension-bindings import.

   gcloud beta service-extensions extension-bindings import ext-binding-iap \
       --source=extension-binding-iap.yaml \
       --location=REGION
   

Pour en savoir plus, consultez Déléguer l'autorisation à IAP.

Étape 2 : Associer Model Armor pour la désinfection des requêtes et des réponses

Pour vous protéger contre l'injection de prompt, les contenus toxiques et les fuites de données sensibles, associez Model Armor à votre passerelle d'agent en procédant comme suit :

1. Créez un fichier de configuration nommé ext-binding-model-armor.yaml.

   name: ext-binding-model-armor
   target:
     resources:
     - "//networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME"
   failOpen: false
   producerExtension: modelarmor.googleapis.com
   producerMetadata:
     model_armor_settings: '[
       {
         "request_template_id": "projects/PROJECT_ID/locations/REGION/templates/REQUEST_TEMPLATE_ID",
         "response_template_id": "projects/PROJECT_ID/locations/REGION/templates/RESPONSE_TEMPLATE_ID"
       }
     ]'
   matchConditions:
   - to:
       destination:
         resources:
         - prefix: "urn:mcp"
   

   Remplacez les éléments suivants :

   • PROJECT_ID : ID de votre projet Google Cloud
   • REGION : région dans laquelle la liaison d'extension est créée
   • AGENT_GATEWAY_NAME : nom de l'Agent Gateway.
   • REQUEST_TEMPLATE_ID : ID du modèle de requête Model Armor
   • RESPONSE_TEMPLATE_ID : ID du modèle de réponse Model Armor

2. Pour importer la liaison d'extension, exécutez la commande gcloud beta service-extensions extension-bindings import.

   gcloud beta service-extensions extension-bindings import ext-binding-model-armor \
       --source=extension-binding-model-armor.yaml \
       --location=REGION
   

Pour en savoir plus, consultez Déléguer l'autorisation à Model Armor et Exemple 3 : Activer l'inspection approfondie de la charge utile avec Model Armor à l'aide de liaisons d'extension dans Configurer des règles d'autorisation pour Secure Web Proxy.

Restreindre les outils MCP à l'aide de règles d'autorisation

Pour limiter la découverte et l'exécution des outils de l'agent aux outils approuvés, créez et importez une règle d'autorisation en procédant comme suit :

1. Créez un fichier de configuration nommé authz-policy-restrict-mcp-tools.yaml.

   name: authz-policy-restrict-mcp-tools
   target:
     resources:
     - "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME"
   policyProfile: REQUEST_AUTHZ
   httpRules:
   - to:
       operations:
       - mcp:
           baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS
           methods:
           - name: "tools/list"
           - name: "tools/call"
             params:
             - exact: "get_weather"
             - exact: "get_location"
   action: ALLOW
   

   Remplacez les éléments suivants :

   • PROJECT_ID : ID de votre projet Google Cloud
   • REGION : région dans laquelle la stratégie d'autorisation est créée
   • AGENT_GATEWAY_NAME : nom de l'Agent Gateway.

2. Pour importer la stratégie d'autorisation, exécutez la commande gcloud network-security authz-policies import.

   gcloud network-security authz-policies import authz-policy-restrict-mcp-tools \
       --source=authz-policy-restrict-mcp-tools.yaml \
       --location=REGION \
       --project=PROJECT_ID
   

Acheminer les agents via Agent Gateway

Après avoir configuré votre Agent Gateway et lui avoir associé des règles d'autorisation, vous devez configurer vos environnements Agent Runtime pour qu'ils dirigent leur trafic sortant vers votre instance Secure Web Proxy. Le routage du trafic sortant s'effectue de manière transparente au niveau de la couche réseau, en redirigeant les requêtes vers la passerelle sans modifier le code de votre application d'agent.

Selon l'emplacement d'exécution de vos charges de travail d'IA, consultez les ressources de documentation suivantes pour configurer le routage sortant :

• GKE : utilisez la mise en réseau ambiante Cloud Service Mesh pour intercepter le trafic sortant de l'agent au niveau du nœud, puis le transférer via un tunnel HTTP CONNECT vers votre instance Secure Web Proxy. Pour configurer des règles de routage sur votre cluster, consultez Router le trafic de sortie ambiant via Secure Web Proxy et Agent Gateway pour GKE.
• Cloud Run : configurez la sortie VPC directe pour envoyer le trafic sortant de l'agent vers votre réseau VPC, où la mise en réseau ambiante Cloud Run redirige les requêtes vers votre instance Secure Web Proxy via un tunnel HTTP CONNECT qui transporte l'identité de l'agent. Pour configurer le routage du trafic sortant, consultez VPC direct avec un réseau VPC et Agent Gateway pour Cloud Run.

Télémétrie, journalisation et surveillance

Lorsque votre passerelle Secure Web Proxy est associée à une ressource Agent Gateway, les journaux de transactions sont émis sous la ressource surveillée Secure Web Proxy standard networkservices.googleapis.com/Gateway. La journalisation est activée par défaut avec un taux d'échantillonnage de 1.0.

Journalisation

Les entrées de journal dans Cloud Logging utilisent le format LoadBalancerLogEntry et contiennent les champs de charge utile de sécurité et d'agent IA suivants :

• agentGatewayInfo : contient des métadonnées sur la transaction de l'agent :

  • agentRegistryResource : nom complet de la ressource de la cible du registre d'agents correspondante, par exemple un serveur MCP ou une compétence
  • destinationUrn : informations sur l'URN de destination
  • mcpInfo : détails de l'appel MCP JSON-RPC, y compris la méthode (par exemple, tools/call ou resources/read), et le nom de l'outil ou l'URI de la ressource

• authzPolicyInfo : résultats de l'évaluation de l'autorisation (ALLOWED ou DENIED) et noms des règles correspondantes

• tls : détails de la négociation TLS et attributs de validation du certificat client cryptographique (mTLS), tels que clientCertPresent et clientCertSha256Fingerprint

Métriques de surveillance

Agent Gateway exporte les métriques suivantes vers Cloud Monitoring :

• Durée du MCP :

  • gcp.mcp.server.operation.duration : latence des opérations effectuées par le serveur d'outils MCP
  • gcp.mcp.client.operation.duration : durée de l'aller-retour de bout en bout d'un appel client MCP

• Latence HTTP :

  • http.server.request.duration : latence d'exécution des requêtes d'agent entrantes traitées par la passerelle
  • http.client.request.duration : latence des requêtes sortantes du proxy vers des destinations externes

• Débit du trafic :

  • gcp.server.request.total_size et gcp.server.response.total_size : taille en octets des requêtes et des réponses que la passerelle reçoit et envoie
  • gcp.client.request.total_size et gcp.client.response.total_size : taille en octets des requêtes et des réponses que la passerelle envoie aux destinations externes

Étapes suivantes

• Configurer des règles d'autorisation pour les destinations agentiques
• Afficher les journaux des transactions du proxy
• Déployer Secure Web Proxy en tant que service Private Service Connect
• Présentation d'Agent Gateway