Pattern di networking privato multi-agente in Google Cloud

Last reviewed 2026-11-09 UTC

Questo documento fornisce indicazioni per aiutarti a progettare un'infrastruttura di networking privato che supporti un'app Gemini Enterprise multi-agente accessibile pubblicamente con connessioni private tra agenti, subagenti e strumenti. Il design della rete fornisce connessioni private per gli agenti ospitati in Agent Runtime su Gemini Enterprise Agent Platform, Cloud Run, Google Kubernetes Engine (GKE), data center on-premise o in altri cloud. Il design supporta anche la connettività agli agenti in esecuzione in località internet.

I sistemi di AI multi-agente spesso coinvolgono dati proprietari o sensibili per l'organizzazione. La rete privata ti consente di evitare di esporre questo traffico alla rete internet pubblica. Questo design utilizza l'infrastruttura di rete Google Cloud , le risorse di rete Virtual Private Cloud (VPC) e la connettività privata ad ambienti on-premise o reti cross-cloud.

Nel design descritto in questo documento, gli agenti comunicano con altri agenti e con gli strumenti utilizzando il protocollo Agent2Agent (A2A) e il Model Context Protocol (MCP). Le comunicazioni vengono rese private instradandole attraverso una rete VPC. Per spostare il traffico in entrata e in uscita dalla rete VPC, questo design utilizza una combinazione di endpoint Private Service Connect, interfacce Private Service Connect e traffico in uscita VPC diretto di Cloud Run. Cloud Next Generation Firewall (Cloud NGFW) gestisce il traffico che passa attraverso la rete VPC. Ulteriori livelli di sicurezza forniscono un traffico in uscita verso internet controllato utilizzando Secure Web Proxy e forniscono policy di accesso ai servizi API utilizzando un perimetro dei Controlli di servizio VPC.

Il pubblico di destinazione di questo documento include architetti, sviluppatori e amministratori che creano e gestiscono app e infrastrutture di AI Cloud. Questo documento presuppone che tu abbia una conoscenza di base degli agenti e dei modelli di AI e che tu abbia familiarità con i concetti di networking di Google Cloud .

Design pattern multi-agente

Un'app Gemini Enterprise multi-agente richiede un agente personalizzato che funga da orchestratore o agente principale per le connessioni a strumenti e subagenti. Per implementare connessioni private a strumenti e subagenti ospitati inGoogle Cloud o on-premise, il design utilizza una rete VPC con indirizzi IP privati. L'agente root è ospitato nell'infrastruttura di Google, utilizzando Agent Runtime, Cloud Run o GKE. Il pattern di progettazione multi-agente evidenzia queste interazioni:

  1. App Gemini Enterprise che interagisce con agenti root personalizzati. Le app Gemini Enterprise presentano un'interfaccia utente gestita con funzioni di sicurezza integrate che espongono la funzionalità dell'agente personalizzato. Gli agenti root personalizzati vengono registrati con Gemini Enterprise e resi disponibili nelle app per gli utenti finali. L'agente principale personalizzato funge da orchestratore del workflow di primo livello e delega le attività specializzate ai sub-agenti. Questa architettura utilizza agenti root personalizzati ospitati su Agent Runtime, Cloud Run o GKE.
  2. Agenti principali che interagiscono con subagenti e strumenti. Il nucleo del flusso di lavoro e della logica di business del sistema di AI risiede nell'agente principale e negli agenti secondari specializzati. La flessibilità del framework, del runtime e della piattaforma di hosting dell'agente consente diverse opzioni per connettere gli agenti principali ai subagenti e agli strumenti tramite la rete VPC. Utilizzando il networking VPC per questa parte dell'architettura, gli agenti possono utilizzare i percorsi di networking privato che definisci, che espongono altri endpoint privati, controlli di sicurezza aziendali e una connettività di rete più ampia.

Panoramica di alto livello di un'architettura di networking multi-agente.

L'architettura include i seguenti componenti:

  • App Gemini Enterprise: il frontend che consente agli utenti di accedere a un'interfaccia di chat in-app e interagire con il sistema AI multi-agente. Gli utenti possono accedere alle app Gemini Enterprise tramite la rete internet pubblica o privatamente tramite connessioni ibride.
  • Agenti personalizzati: agenti root creati e registrati con Gemini Enterprise e ospitati su Agent Runtime, Cloud Run o GKE. Questi agenti principali fungono da orchestratori che delegano le attività ai subagenti.
  • Rete VPC: una risorsa che controlli per fornire agli agenti la connettività di rete IP agli endpoint privati e una maggiore raggiungibilità della rete. La rete VPC fornisce una piattaforma per implementare la connettività privata e i controlli di sicurezza di rete per le richieste degli agenti ad altri agenti e strumenti.
  • Subagenti: agenti specializzati attivati dal workflow dell'agente principale. I subagenti comunicano utilizzando il protocollo A2A, che consente l'interoperabilità tra gli agenti indipendentemente dal linguaggio di programmazione e dal runtime.
  • Strumenti: sistemi remoti che espongono servizi come API, origini dati e funzioni di workflow. Questi strumenti recuperano i dati ed eseguono azioni o transazioni per gli agenti. Gli strumenti sono esterni agli agenti, che si connettono e interagiscono con gli strumenti utilizzando la specifica MCP.

Questo pattern di progettazione multi-agente di alto livello evidenzia i componenti di networking che si trovano in un sistema di AI multi-agente. Può supportare molti tipi diversi di pattern di routing da agente ad agente. Per informazioni su altri pattern di progettazione di sistemi di AI, consulta Scegli un pattern di progettazione per il tuo sistema di AI agentica.

VPC condiviso

Il pattern di progettazione multi-agente utilizza il VPC condiviso per centralizzare l'autorità e la responsabilità di networking e sicurezza. Questo design fornisce agli sviluppatori ambienti che contribuiscono a soddisfare le esigenze di sicurezza di un'organizzazione. Ti consigliamo di utilizzare il VPC condiviso per centralizzare e semplificare le configurazioni di rete e sicurezza.

In un'architettura VPC condivisa, un progetto host contiene le risorse di rete condivise, tra cui reti VPC, router Cloud, subnet, firewall e Cloud DNS. Gli amministratori possono concedere ai progetti di servizio l'accesso per utilizzare queste risorse. I progetti di servizio contengono le risorse di runtime degli agenti, tra cui Agent Runtime, Cloud Run, GKE, Gemini Enterprise e i bilanciatori del carico specifici per le app.

Il VPC condiviso applica un confine netto tra i ruoli di amministratore di rete e di sicurezza e i ruoli di sviluppatore di app di AI:

  • Gli amministratori di rete e della sicurezza controllano l'infrastruttura di base, come il routing VPC, le subnet, il peering DNS e le policy del firewall.
  • Gli sviluppatori di app di AI creano agenti nei progetti di servizio collegati senza disporre delle autorizzazioni per modificare l'infrastruttura di rete sottostante.

Quando centralizzi i deployment di rete e sicurezza all'interno di un progetto host, crei un unico punto di gestione per la comunicazione tra agenti e tra agenti e servizi. Questo design semplifica l'applicazione delle policy di sicurezza in molti progetti di servizi diversi, garantendo al contempo una connettività coerente.

Puoi incorporare la tua rete VPC condiviso in una Cross-Cloud Network utilizzando gli spoke VPC di Network Connectivity Center (NCC) per aggiungere la rete VPC condiviso come rete VPC del workload. Questa implementazione fornisce al VPC condiviso la piena raggiungibilità delle route dell'hub NCC e la connettività ai punti di accesso ai servizi da altri spoke.

Le richieste avviate dagli agenti root personalizzati utilizzano una rete VPC privata gestita dal cliente per fornire percorsi di rete sicuri ad agenti secondari, strumenti e servizi. Il routing della rete VPC regola la raggiungibilità degli endpoint privati. Le policy di Cloud NGFW applicate alla rete VPC regolano l'accesso alla rete.

Gli agenti ottengono l'accesso sicuro ai percorsi di rete VPC privati, inclusa la connettività ai seguenti elementi:

  • Altre reti VPC tramite peering di rete VPC, appliance multi-NIC o NCC.
  • Endpoint Private Service Connect per accedere ai servizi del producer.
  • Servizi gestiti con indirizzi IP privati, ad esempio Cloud SQL.
  • Frontend del bilanciatore del carico interno e risorse Compute Engine.
  • API di Google tramite l'accesso privato Google o tramite Private Service Connect.
  • Internet, controllato tramite Secure Web Proxy.
  • Destinazioni ibride e cross-cloud utilizzando Cloud Interconnect, Cloud VPN, l'appliance router o SD-WAN.
  • Qualsiasi destinazione endpoint raggiungibile tramite il routing IP della rete VPC.
  • Altri agenti AI, strumenti e servizi di supporto.

Per ulteriori informazioni sul VPC condiviso, consulta queste risorse:

Networking di Gemini Enterprise

Le app Gemini Enterprise sono risorse gestite che operano in un ambiente in hosting esterno alla rete VPC, ma all'interno della rete di Google. Le sezioni seguenti descrivono la configurazione del networking tra l'utente e l'app Gemini Enterprise e il networking tra l'app e gli agenti.

Chat degli utenti con le app Gemini Enterprise

Gli utenti interagiscono con l'app Gemini Enterprise utilizzando un'app basata su browser che invia richieste alle API e ai servizi di Google. Per abilitare la connettività utente privata, puoi configurare gli URL delle API di Google in modo che vengano risolti in intervalli di indirizzi IP privati instradati sulla tua rete VPC. Per saperne di più, consulta Configura l'accesso privato alla UI.

App Gemini Enterprise agli agenti personalizzati

Registra gli agenti personalizzati con il servizio di discovery di Gemini Enterprise. Quando registri un agente, Gemini Enterprise mappa il nome dell'agente a un target specifico, ovvero l'URI della risorsa di runtime dell'agente o l'URL dell'agente A2A. Le app Gemini Enterprise hanno un'interfaccia di chat integrata chiamata assistente. Quando un utente specifica un agente utilizzando @agent_name o quando l'assistente decide di delegare, l'app cerca l'agente nel registry per trovare l'endpoint associato.

Quando registri un agente root con Gemini Enterprise, puoi eseguirne il deployment ovunque come agente personalizzato. Gli agenti personalizzati su Agent Runtime e su Cloud Run possono utilizzare i percorsi di rete privata esistenti senza configurare risorse di networking aggiuntive. Per eseguire il deployment di un agente personalizzato su GKE, devi esporre il servizio con un gateway esterno. Per informazioni su come configurare il gateway esterno in modo che sia più sicuro, consulta Networking GKE più avanti in questo documento.

Per effettuare richieste agli agenti personalizzati, Gemini Enterprise utilizza l'identità del service account Discovery Engine di Gemini Enterprise Agent Platform. Il percorso di rete e i meccanismi di autorizzazione variano in base alla piattaforma di hosting che utilizzi:

  • Agenti personalizzati su Agent Runtime: l'agente di servizio Discovery Engine di Agent Platform include i ruoli Identity and Access Management (IAM) di Agent Platform necessari per richiamare le risorse di Agent Runtime come funzionalità integrata. Il sistema instrada le richieste effettuate al servizio API Agent Platform sulla rete Google come chiamata API interna.
  • Agenti personalizzati su Cloud Run: le app Gemini Enterprise utilizzano l'identità dell'agente di servizio Discovery Engine della piattaforma agentica per effettuare chiamate all'URL .run.app predefinito registrato dalla scheda dell'agente, allegando il token ID OIDC dell'agente di servizio nell'intestazione di autenticazione X-Serverless-Authorization. Affinché il servizio Cloud Run dell'agente AI possa autorizzare queste chiamate, devi concedere il ruolo IAM Invoker di Cloud Run (roles/run.invoker) all'agente di servizio Discovery Engine. Le richieste a Cloud Run vengono instradate sulla rete di produzione di Google verso l'ingresso Google Front End (GFE) per Cloud Run.

  • Agenti personalizzati su GKE: le app Gemini Enterprise utilizzano l'identità dell'agente di servizio Agent Platform Discovery Engine per effettuare chiamate all'URL registrato dalla scheda dell'agente. Il DNS pubblico deve essere in grado di risolvere il nome host in un indirizzo IP esterno gestito dal gateway. Ti consigliamo di utilizzare il bilanciatore del carico gke-l7-regional-external-managed o il bilanciatore del carico gke-l7-global-external-managed. Per una maggiore sicurezza, ti consigliamo di fare in modo che Gemini Enterprise chiami un agente A2A ospitato su GKE utilizzando Identity-Aware Proxy (IAP). Affinché IAP possa autorizzare queste chiamate, devi concedere il ruolo IAM Utente applicazione web con protezione IAP (roles/iap.httpsResourceAccessor) all'agente di servizio Discovery Engine. La rete di produzione di Google instrada le richieste a GKE verso il GFE per l'ingresso del bilanciatore del carico delle applicazioni esterno.

    Per proteggere GKE Ingress da Gemini Enterprise, consulta le sezioni IAP e Google Cloud Armor più avanti in questo documento.

Networking privato per le piattaforme di hosting degli agenti

Dopo che un utente avvia una richiesta all'app Gemini Enterprise, le richieste vengono avviate dagli agenti root personalizzati ai subagenti e agli strumenti. Le piattaforme di hosting degli agenti personalizzati forniscono l'interfaccia tra Gemini Enterprise e le tue reti VPC. Le piattaforme di hosting per gli agenti e gli strumenti containerizzati sono Agent Runtime, Cloud Run e GKE.

Quando scegli una piattaforma di hosting degli agenti, devi considerare i pattern di networking privato, i controlli di sicurezza, il controllo di gestione, il livello di personalizzazione e la conformità della sicurezza di ogni piattaforma. Per saperne di più su come selezionare una piattaforma di hosting di agenti AI, consulta Scegli modelli e infrastruttura per la tua applicazione di AI generativa e Scegli i componenti dell'architettura di AI agentica.

La connettività VPC privata viene stabilita tramite meccanismi diversi in base alla piattaforma di hosting degli agenti che utilizzi:

  • Agenti personalizzati su Agent Runtime: le interfacce Private Service Connect collegano i runtime di Agent Runtime alla rete VPC. Crea un collegamento di rete in una subnet della tua rete VPC e concedi l'autorizzazione di runtime dell'agente per collegarlo. Il traffico inviato da Agent Runtime viene visualizzato nella rete VPC come se avesse avuto origine dall'indirizzo IP della subnet del collegamento. La rete VPC instrada quindi il traffico all'indirizzo IP di destinazione appropriato.
  • Agenti personalizzati su Cloud Run: il traffico in uscita VPC diretto di Cloud Run connette le istanze del servizio Cloud Run alla rete VPC. La rete VPC specificata quando viene eseguito il deployment di un servizio Cloud Run può provenire dal progetto di servizio Cloud Run o dal relativo progetto host VPC condiviso. Il traffico inviato da Cloud Run viene visualizzato nella rete VPC come se provenisse dall'indirizzo IP della subnet del traffico in uscita VPC diretto. La rete VPC instrada quindi il traffico all'indirizzo IP di destinazione appropriato.
  • Agenti personalizzati su GKE: i cluster GKE si trovano direttamente nella rete VPC e utilizzano indirizzi IP di subnet locali. Per impostazione predefinita, il traffico in uscita di GKE utilizza l'indirizzo IP del pod come indirizzo IP di origine. Se configuri il mascheramento, il traffico in uscita di GKE utilizza l'indirizzo IP del nodo come indirizzo IP di origine. Tutto il traffico in uscita di GKE viene instradato dalla rete VPC.

Le sezioni seguenti forniscono indicazioni aggiuntive per la gestione delle richieste in entrata e in uscita dalla rete VPC per ogni piattaforma di hosting degli agenti. Le considerazioni sulla rete sono applicabili sia alla funzionalità dell'agente principale sia a quella del sub-agente.

Networking di Agent Runtime

Questa sezione descrive il networking privato per gli agenti principali e secondari ospitati su Agent Runtime. Se utilizzi Agent Runtime per ospitare l'agente root, devi eseguire il deployment di Gemini Enterprise e Agent Runtime nello stesso progetto.

Agent Runtime ospita i container sull'infrastruttura Google all'esterno della tua rete VPC. Per abilitare la connettività privata ad altri agenti, puoi connettere il tuo agente alla rete VPC utilizzando i seguenti metodi:

Per consentire le richieste tra i tuoi agenti e altri agenti, configura entrambe le connessioni precedenti.

Traffico in uscita dall'Agent Runtime alla rete VPC

Agent Runtime utilizza un progetto tenant gestito da Google per il traffico in uscita dalla rete. La rete tenant fornisce la connettività per gli agenti alle API di Google e per il traffico in uscita verso internet pubblico, ma non è connessa direttamente alle reti VPC dei clienti per impostazione predefinita.

Per connettere gli agenti alle risorse all'interno della tua rete VPC, Agent Runtime utilizza le interfacce Private Service Connect. Agent Runtime esegue il deployment di un'interfaccia di rete nel progetto tenant che si connette a una risorsa di collegamento di rete nel tuo progetto. Questa connessione crea un percorso dei dati sicuro tra il runtime di Agent Runtime e la rete VPC. Quando configuri un'interfaccia di Private Service Connect nel progetto Agent Runtime, il sistema instrada tutto il traffico dell'agente non destinato alle API di Google alla rete VPC.

Per eseguire il deployment del traffico in uscita dalla rete VPC di Agent Runtime, consulta queste risorse:

Per proteggere ulteriormente gli agenti e la rete VPC per il traffico in uscita di Agent Runtime, consulta queste sezioni più avanti in questo documento:

Traffico in entrata di Agent Runtime dalla rete VPC

Le richieste agli agenti in esecuzione su Agent Runtime vengono effettuate utilizzando l'endpoint API Agent Platform (aiplatform.googleapis.com). Per raggiungere gli endpoint API di Google utilizzando percorsi di rete privati dalla rete VPC, utilizza l'accesso privato Google o gli endpoint Private Service Connect per le API di Google.

Gli utenti privati che eseguono query sugli agenti devono risolvere il nome host dell'endpoint API Agent Platform nell'intervallo di indirizzi IP privati per l'accesso privato Google o nell'indirizzo IP dell'endpoint Private Service Connect per le API di Google. Una zona Cloud DNS gestita privata per googleapis.com risolve le richieste per l'API Agent Platform. La rete VPC instrada la richiesta direttamente sulla rete di produzione di Google.

Se utilizzi l'accesso privato Google o Private Service Connect per le API di Google, puoi contribuire a proteggere il traffico dalla tua rete VPC ad Agent Runtime utilizzando i seguenti prodotti e funzionalità:

Considerazioni aggiuntive sulla rete di Agent Runtime

Il traffico in uscita dell'Agent Runtime che utilizza le interfacce Private Service Connect può essere instradato solo agli intervalli di indirizzi IP RFC 1918 nella rete VPC. Per intervalli di destinazione specifici che non possono essere instradati dal traffico in uscita di Agent Runtime, consulta Requisiti degli intervalli IP delle subnet. Per raggiungere destinazioni con intervalli di indirizzi IP non instradabili, utilizza una configurazione proxy esplicita sugli agenti ed esegui il deployment di risorse proxy che utilizzano un indirizzo IP instradabile nella rete VPC.

Quando viene eseguito il deployment di Agent Runtime senza un'interfaccia Private Service Connect, l'accesso a internet è disponibile per impostazione predefinita. Per proteggerti dall'esfiltrazione di dati, disattiva l'accesso predefinito attivando i Controlli di servizio VPC.

Quando viene eseguito il deployment di Agent Runtime con un'interfaccia Private Service Connect, il traffico in uscita verso internet diretto è disabilitato, indipendentemente dai Controlli di servizio VPC. Se hai bisogno che l'agente acceda a una destinazione che Agent Runtime non può raggiungere normalmente, ad esempio internet, segui questi passaggi:

  1. Configura Secure Web Proxy in una subnet RFC 1918 della tua rete VPC. Devi configurare il proxy in modalità di routing del proxy esplicito.
  2. Crea un record Cloud DNS per il nome host di Secure Web Proxy.
  3. Configura il peering DNS per Agent Runtime in modo da supportare la risoluzione delle query DNS dell'agente all'indirizzo privato di Secure Web Proxy nella rete VPC.
  4. Quando esegui il deployment degli agenti, segui questi passaggi:
    1. Definisci le variabili di ambiente per utilizzare il proxy esplicito specificando il nome host e la porta di Secure Web Proxy.
    2. Se accedi a una destinazione privata, configura una zona DNS privata per quella destinazione.

Una volta che il traffico in uscita dal runtime dell'agente raggiunge la rete VPC, può raggiungere qualsiasi destinazione di rete instradabile dalla rete VPC. Per informazioni su come limitare l'ambito delle destinazioni di rete in uscita disponibili per gli agenti Agent Runtime, consulta la sezione Cloud NGFW più avanti in questo documento.

Networking di Cloud Run

Questa sezione descrive il networking privato per gli agenti root e gli agenti secondari ospitati su Cloud Run. Cloud Run ospita i container sull'infrastruttura Google all'esterno della tua rete VPC. Per abilitare la connettività privata ad altri agenti, puoi connettere il tuo agente alla rete VPC utilizzando i seguenti metodi:

Per consentire le richieste tra i tuoi agenti e altri agenti, configura entrambe le connessioni precedenti.

Traffico in uscita da Cloud Run alla rete VPC

Per avviare le connessioni di Cloud Run a una rete VPC, ti consigliamo di utilizzare il traffico VPC diretto in uscita. Con il VPC diretto in uscita, le istanze Cloud Run si connettono direttamente alla rete VPC condivisa utilizzando un indirizzo IP della subnet che specifichi quando esegui il deployment del VPC diretto in uscita.

Quando configuri il VPC diretto in uscita, segui questi passaggi:

  1. Configura la subnet di destinazione con l'accesso privato Google abilitato.
  2. Configura il routing del traffico per instradare tutto il traffico alla rete VPC.

Questa configurazione invia tutto il traffico attraverso la rete VPC per motivi di privacy e invia le richieste da Cloud Run ad altre API di Google tramite la rete interna di Google.

Tutte le query DNS da Cloud Run utilizzano la policy e le zone Cloud DNS associate alla rete VPC. Non è necessaria alcuna configurazione aggiuntiva del peering DNS. Gli agenti ospitati su Cloud Run risolvono tutte le zone private e i nomi host pubblici di Cloud DNS.

Per informazioni su come proteggere ulteriormente gli agenti e la rete VPC per il traffico in uscita di Cloud Run, consulta queste sezioni più avanti in questo documento:

Traffico in entrata di Cloud Run dalla rete VPC

Cloud Run è una piattaforma gestita da Google che opera in un ambiente esterno alla rete VPC. Questo ambiente ospita l'endpoint URL *.run.app stabile per i servizi Cloud Run che eseguono workload di agenti o strumenti AI. Questi endpoint sono gestiti dallo stesso entry point GFE che gestisce i servizi API *.googleapis.com. Cloud Run utilizza gli stessi percorsi di rete sottostanti che abilitano la connettività privata per l'accesso privato Google e per Private Service Connect per le API di Google.

Gli utenti privati della rete VPC che eseguono query su agenti o strumenti devono risolvere il nome host run.app nell'intervallo di indirizzi IP privati per l'accesso privato Google o nell'indirizzo IP dell'endpoint Private Service Connect per le API di Google. Una zona Cloud DNS privata gestita per l'URL run.app risolve le richieste per i servizi Cloud Run. La rete VPC instrada la richiesta direttamente sulla rete di produzione di Google.

L'impostazione del traffico in entrata di Cloud Run su Interno limita l'accesso al servizio consentendo le richieste solo da origini interne verificate. Le fonti approvate includono:

  • Reti VPC del progetto di servizio Cloud Run.
  • La rete VPC condivisa che ospita l'endpoint di traffico in uscita VPC diretto.
  • Risorse che si trovano all'interno dello stesso perimetro dei Controlli di servizio VPC.
  • Bilanciatori del carico delle applicazioni interni nella rete VPC.
  • Servizi Google come Cloud Scheduler e Pub/Sub che si trovano all'interno del progetto di servizio o del perimetro dei Controlli di servizio VPC.

Se non utilizzi un perimetro dei Controlli di servizio VPC comune per includere sia i servizi chiamanti che quelli chiamati, il traffico proveniente dall'esterno del progetto del servizio Cloud Run o dell'ambiente VPC condiviso viene trattato come esterno. Questo traffico include il traffico proveniente da altri servizi Google Cloud, come Agent Runtime e altri servizi Cloud Run. Per soddisfare il controllo del traffico in entrata interno di Cloud Run, questo traffico deve essere instradato in modo che sembri provenire dalla rete VPC del servizio di destinazione.

Per fornire l'attribuzione della rete interna necessaria, puoi procedere in uno dei seguenti modi:

  • Utilizza gli endpoint di Private Service Connect per consentire ai servizi in altri VPC o progetti di connettersi alle API di Google e ai servizi, incluso il servizio Cloud Run, utilizzando un indirizzo IP privato all'interno della tua rete VPC.
  • Instrada il traffico attraverso un bilanciatore del carico delle applicazioni interno posizionato all'interno della tua rete VPC davanti al tuo servizio Cloud Run. Il bilanciatore del carico convoglia le richieste di altri servizi attraverso la rete VPC in modo che soddisfino i criteri di traffico in entrata interno.

I bilanciatori del carico delle applicazioni interni con backend di gruppi di endpoint di rete (NEG) serverless creano una risorsa VPC mappata direttamente a un servizio Cloud Run. In questo modello, il bilanciatore del carico termina le connessioni TLS client con un certificato attendibile. I bilanciatori del carico delle applicazioni interni supportano controlli di sicurezza aggiuntivi, tra cui le policy di sicurezza del backend di Cloud Armor e altre policy di autorizzazione.

Per impostazione predefinita, l'accesso a tutti i servizi Cloud Run richiede l'autenticazione IAM. Ti consigliamo di utilizzare un'identità per servizio e di concedere all'entità il ruolo IAM Cloud Run Invoker (roles/run.invoker).

Per informazioni su come configurare i controlli in entrata di Cloud Run, consulta queste risorse:

Se utilizzi l'accesso privato Google o gli endpoint Private Service Connect per le API di Google per inviare traffico dalla tua rete VPC a Cloud Run, puoi contribuire a proteggere questo traffico utilizzando i seguenti prodotti e funzionalità:

Se utilizzi un bilanciatore del carico delle applicazioni interno per inviare traffico dalla tua rete VPC a Cloud Run, puoi contribuire a proteggere questo traffico utilizzando i seguenti prodotti e funzionalità:

Networking di GKE

Questa sezione descrive il networking per gli agenti basati su GKE.

GKE e Gemini Enterprise

In qualità di host per agenti e strumenti AI, GKE offre una piattaforma altamente personalizzabile per i controlli di rete e sicurezza. Un sistema di AI multi-agente di cui è stato eseguito il deployment su GKE può fornire efficienza operativa su larga scala. Può integrarsi perfettamente con altre app Kubernetes e con architetture di microservizi più ampie.

I cluster GKE sono nodi VM di Compute Engine che vengono eseguiti all'interno di una subnet della rete VPC. Le app Gemini Enterprise sono risorse gestite che operano in un ambiente ospitato esterno alla rete VPC. Per consentire alle app Gemini Enterprise di chiamare agenti personalizzati ospitati su GKE, devi esporre in modo sicuro un gateway esterno con un indirizzo IP pubblico e un nome DNS. Il traffico passa dall'uscita di Gemini Enterprise alla rete perimetrale di Google, dove segue un percorso ottimizzato verso il bilanciatore del carico esterno di GKE.

È importante proteggere l'endpoint GKE utilizzando un'autenticazione e un'autorizzazione efficaci, Cloud Armor e autorizzazioni limitate. Per fornire un modello di difesa in profondità completo per proteggere gli agenti AI eseguiti su GKE, prendi in considerazione i controlli di sicurezza descritti nelle sezioni seguenti.

Modalità operativa di GKE

GKE offre queste modalità di funzionamento per bilanciare gestione e controllo:

  • Autopilot: Google automatizza l'intera infrastruttura del cluster GKE, inclusi il control plane, il provisioning dei nodi, il rafforzamento della sicurezza e la scalabilità.
  • Standard: Google gestisce il control plane. La responsabilità delle configurazioni pool di nodi, come la selezione dei tipi di macchine, la gestione delle immagini sistema operativo e la scalabilità manuale, rimane interamente tua.
Rafforzamento dell'infrastruttura e del control plane
  • Cluster GKE privati: esegui il provisioning dei nodi senza indirizzi IP pubblici, per garantire che l'ambiente di runtime sia isolato dall'esposizione diretta a internet.
  • Reti autorizzate master: limita l'accesso amministrativo all'API Kubernetes a intervalli di indirizzi IP specifici e attendibili, rafforzando il control plane contro le modifiche alla configurazione non autorizzate. Proteggi l'endpoint DNS per l'API Kubernetes utilizzando IAM e i Controlli di servizio VPC di Google Cloud.
Identità e accesso (Zero Trust)
  • IAP: funge da gatekeeper a livello di bilanciatore del carico. In questo modo, solo gli utenti autenticati con le autorizzazioni IAM corrette possono accedere all'endpoint dell'agente. Questo approccio sposta efficacemente il perimetro di sicurezza dalla rete al singolo utente e al contesto del suo dispositivo.
Protezione perimetrale e gestione del traffico
  • Cloud Armor: fornisce una solida sicurezza perimetrale, incluse regole WAF (Web Application Firewall) per bloccare i payload dannosi, protezione DDoS per garantire l'uptime e limitazione di frequenza per prevenire l'esaurimento dei servizi.
  • Model Armor: progettato specificamente per la sicurezza degli LLM, Model Armor ispeziona e sanitizza i prompt e le risposte in tempo reale per impedire prompt injection ed esfiltrazione di dati.
Isolamento della rete interna
  • Policy di rete di Kubernetes: applicano una comunicazione granulare con privilegi minimi tra i microservizi. Per impostazione predefinita, le policy negano tutto il traffico, a meno che non lo consenti esplicitamente, il che impedisce il movimento laterale all'interno del cluster.

Traffico in uscita da GKE alla rete VPC

La rete VPC instrada le connessioni in uscita dagli agenti ospitati su GKE. La modalità di rete predefinita del cluster GKE è VPC nativo, che fornisce i seguenti attributi:

  • Il cluster GKE utilizza intervalli di indirizzi IP alias.
  • Gli indirizzi IP dei pod vengono riservati specificando l'intervallo IP dei pod.
  • Gli indirizzi IP dei pod sono instradabili in modo nativo all'interno della rete VPC del cluster e di altre reti VPC connesse.

Se un pod agente comunica con un pod subagente nello stesso nodo, il traffico viene instradato localmente all'interno dello spazio dei nomi di rete del nodo. Se il pod dell'agente di destinazione si trova su un nodo diverso all'interno del cluster, il traffico viene instradato utilizzando la tabella di routing della rete VPC. Per comunicare con altre risorse VPC come i bilanciatori del carico o gli endpoint Private Service Connect, un pod agente può raggiungere la destinazione utilizzando lo stesso routing VPC standard, soggetto alle regole firewall.

Puoi contribuire a proteggere il traffico che esce dal cluster GKE utilizzando i seguenti prodotti e servizi:

Traffico GKE in entrata dalla rete VPC

I servizi Kubernetes forniscono l'accesso alle risorse GKE. Per un sistema di AI multi-agente, ti consigliamo di utilizzare un gateway GKE o un GKE Inference Gateway. Il gateway offre funzionalità avanzate con controllo del traffico, separazione operativa delle risorse e integrazioni di sicurezza. Tuttavia, sono disponibili altre opzioni di servizio in entrata a seconda dei requisiti di sistema.

La risorsa Gateway crea un bilanciatore del carico delle applicazioni ed esegue il provisioning di tutti i componenti di bilanciamento del carico necessari. I gruppi di endpoint di rete di backend del servizio sono collegati per fornire il bilanciamento del carico direttamente ai container. Per esporre un servizio internamente per il traffico proveniente dalla rete VPC, utilizza le classi Gateway per il bilanciatore del carico delle applicazioni interno regionale (gke-l7-rilb) o il bilanciatore del carico delle applicazioni interno tra regioni (gke-l7-cross-regional-internal-managed-mc).

I bilanciatori del carico delle applicazioni forniscono punti di controllo di sicurezza aggiuntivi per proteggere gli agenti e gli strumenti AI ospitati sui cluster GKE:

  • Cloud Armor: protegge i servizi collegando una policy di sicurezza Cloud Armor ai servizi di backend gestiti dal gateway. Fornisce screening WAF, filtro basato su indirizzo IP e posizione geografica, protezione DDoS e limitazione di frequenza prima che il traffico raggiunga il cluster GKE o IAP.
  • IAP: abilitato sul servizio di backend per controllare l'accesso alle app utilizzando le credenziali IAM, IAP applica policy di accesso Zero Trust. IAP autentica e autorizza gli agenti AI che accedono alle risorse del cluster, tra cui le app Gemini Enterprise, gli agenti personalizzati e le risorse esterne. Richiede che i chiamanti abbiano un'identità autenticata da IAM e l'autorizzazione per accedere al servizio di backend.

Se invii traffico dalla tua rete VPC al tuo servizio GKE tramite un gateway, puoi contribuire a proteggere il traffico utilizzando i seguenti prodotti e funzionalità:

Se non utilizzi un gateway per inviare il traffico dalla tua rete VPC al tuo servizio GKE, puoi contribuire a proteggere il traffico utilizzando i seguenti prodotti e servizi:

Per saperne di più sulla protezione di GKE, consulta Best practice per la sicurezza di rete e Informazioni sulla sicurezza di rete in GKE.

Sicurezza di rete dell'agente

Per proteggere la rete di un sistema di AI multi-agente, devi proteggere le comunicazioni sia tramite la rete VPC sia tramite la superficie dell'API. Il piano dati della rete VPC gestisce il modo in cui gli agenti e gli strumenti si connettono in modo sicuro. La superficie dell'API definisce quali identità e tipi di scambi di dati sono consentiti. La stratificazione dei controlli degli accessi sia sulla rete VPC sia sulla superficie dell'API aiuta ad applicare una security posture altamente controllata e resiliente.

Cloud NGFW

Cloud NGFW funge da gatekeeper a livello di rete per proteggere le comunicazioni A2A e MCP. Il firewall garantisce che solo il traffico autorizzato possa raggiungere gli endpoint degli agenti verificando ogni connessione in entrata o in uscita da e verso altri agenti e strumenti.

Cloud NGFW è un servizio firewall distribuito integrato nel fabric della rete VPC. Offre questi livelli di funzionalità che operano a diversi livelli dello stack di rete:

  • Cloud Next Generation Firewall Essentials: fornisce il filtro dei pacchetti del firewall stateful. Le regole delle policy vengono definite in base a indirizzi IP (L3), protocolli e porte (L4).
  • Cloud Next Generation Firewall Standard: fornisce l'applicazione basata su IP con oggetti di nomi di dominio completi (FQDN), oggetti di geolocalizzazione e feed di Google Threat Intelligence per bloccare gli indirizzi dannosi noti.
  • Cloud Next Generation Firewall Enterprise: offre funzionalità di ispezione delle app (L7) reali con decrittografia TLS e funzionalità del sistema di rilevamento e prevenzione delle intrusioni (IDPS) per analizzare i payload rispetto alle firme delle minacce avanzate.

Cloud NGFW può essere applicato alla rete VPC per applicare la policy del firewall in base alle regole necessarie per scegliere come target la piattaforma di hosting dell'agente che hai utilizzato.

  • Agent Runtime: gli agenti eseguiti in Agent Runtime si connettono alla rete VPC utilizzando i collegamenti di rete Private Service Connect. Questi collegamenti fanno apparire l'interfaccia di rete dell'agente all'interno di una subnet nella rete VPC. Le policy del firewall di rete Cloud NGFW vengono applicate alla rete VPC. Le policy filtrano il traffico in base agli indirizzi IP di origine della subnet dedicata al collegamento di rete Private Service Connect. Per la corrispondenza del traffico, puoi utilizzare gli intervalli di indirizzi IP di origine e di destinazione.
  • Cloud Run: i servizi Cloud Run che utilizzano il traffico VPC diretto in uscita inviano il traffico direttamente dalle istanze eseguite all'interno di una subnet specificata nella rete VPC. Le policy del firewall di rete Cloud NGFW si applicano alla subnet utilizzata da Cloud Run per filtrare il traffico. Per la corrispondenza del traffico, puoi utilizzare intervalli di indirizzi IP di origine e di destinazione.
  • GKE: i cluster GKE nativi di VPC assegnano ai pod indirizzi IP provenienti direttamente dagli intervalli di indirizzi IP secondari della rete VPC. Le policy del firewall di rete possono filtrare il traffico in base agli intervalli di indirizzi IP per i nodi e i pod GKE e possono utilizzare tag sicuri e service account. I tag sicuri si associano alle istanze VM che fungono da nodi GKE. Le regole firewall possono quindi scegliere come target o origine il traffico proveniente da nodi con tag specifici. Le regole firewall possono anche avere come target o origine il traffico proveniente dai nodi GKE in base all'identità del account di servizio associato al pool di nodi.

Policy di negazione in uscita predefinita

L'implementazione di una strategia di negazione predefinita è una best practice di sicurezza che rispetta il principio del privilegio minimo. Questa strategia garantisce che sia consentito solo il traffico di rete esplicitamente autorizzato, mentre tutto il resto del traffico viene bloccato per impostazione predefinita. Questa implementazione si ottiene strutturando le regole firewall con regole ALLOW ad alta priorità per i flussi legittimi noti e una regola DENY catch-all a bassa priorità. Tutti i livelli di Cloud NGFW consentono regole basate su intervalli di indirizzi IP di origine e di destinazione.

Le regole della policy del firewall possono corrispondere in modo efficace al traffico di origine proveniente dalla subnet del collegamento di rete di Agent Runtime e dalla subnet di VPC diretto in uscita di Cloud Run.

Di seguito è riportato un esempio di policy default-deny in uscita:

  • Crea una policy e delle regole del firewall di rete: crea una policy del firewall globale o regionale e associala alla rete VPC. Crea regole della policy del firewall che hanno come target il traffico in uscita (--direction=EGRESS) in base agli intervalli di indirizzi IP di origine (--src-ip-ranges=SRC_IP_RANGES) e agli intervalli di indirizzi IP di destinazione (--dest-ip-ranges=DEST_IP_RANGES).
  • Regole ALLOW specifiche: utilizza numeri di priorità più bassi, ad esempio 100-1000. Queste regole consentono con precisione il traffico di rete necessario per il funzionamento degli agenti AI. Questo traffico include le comunicazioni con altri servizi interni, bilanciatori del carico, API di Google richieste o endpoint esterni legittimi. Crea una regola che corrisponda al traffico di origine dalla subnet del collegamento di rete di Agent Runtime o dalla subnet del traffico VPC diretto in uscita di Cloud Run alle destinazioni che preferisci.
  • Regola generale DENY: per assicurarti che la regola sia l'ultima nell'ordine di valutazione, utilizza il numero di priorità più alto, ad esempio 2147483647. Questa regola nega il traffico verso qualsiasi destinazione (--dest-ip-ranges=0.0.0.0/0) che non corrisponde a nessuna delle regole ALLOW precedenti.

Una policy di negazione del traffico in uscita predefinita impedisce agli agenti AI di stabilire connessioni di rete non autorizzate esplicitamente e blocca la potenziale esfiltrazione di dati o l'accesso a siti dannosi. La policy limita gli agenti in hosting a comunicare solo con endpoint approvati, il che è fondamentale per mantenere il controllo sui workload autonomi.

Ulteriori considerazioni sulle policy di Cloud NGFW

Oltre alla strategia di negazione predefinita disponibile con tutti i livelli di Cloud NGFW, puoi rafforzare ulteriormente la sicurezza di rete dell'AI multi-agente utilizzando le funzionalità del livello a pagamento:

  • Funzionalità di Cloud NGFW Standard:
    • Oggetti FQDN per endpoint dinamici: gli agenti AI spesso interagiscono con API esterne, endpoint di modelli o origini dati i cui indirizzi IP potrebbero cambiare. Per un accesso coerente ai servizi necessari in base al nome di dominio, utilizza gli oggetti FQDN nelle regole ALLOW.
    • Controlli di geolocalizzazione: se gli agenti AI hanno requisiti di conformità o se non devono interagire con i servizi in regioni geografiche specifiche, utilizza gli oggetti di geolocalizzazione (--src-region-codes=SRC_COUNTRY_CODES) nelle regole del firewall per limitare il traffico da o verso queste località.
    • Google Threat Intelligence: utilizza Google Threat Intelligence nei filtri in uscita per impedire automaticamente agli agenti di connettersi a destinazioni dannose note, come server di comando e controllo (C2), anonimizzatori come Tor e siti di distribuzione di malware. L'utilizzo di Google Threat Intelligence aiuta a contenere l'impatto di un agente potenzialmente compromesso. Ti consigliamo di includere questi filtri di destinazione nelle regole DENY con un numero di priorità più alto (ordine di valutazione più basso).
  • Funzionalità di Cloud NGFW Enterprise:
    • Ispezione di livello 7: per gli agenti che gestiscono dati sensibili o che sono esposti a rischi più elevati, ispeziona i payload dei pacchetti per individuare minacce come malware, spyware ed exploit che non vengono analizzati dalle regole firewall a livello di rete.
    • Ispezione TLS: per consentire al motore di ispezione di analizzare il traffico criptato, abilita l'ispezione TLS. L'utilizzo dell'ispezione TLS è fondamentale perché la maggior parte degli attacchi moderni e delle comunicazioni C2 è crittografata.

Per ulteriori considerazioni o limitazioni relative all'implementazione che potrebbero essere applicabili al tuo ambiente, consulta queste risorse:

IAP

IAP protegge le richieste di traffico in entrata ai cluster GKE fornendo un livello di autenticazione e autorizzazione centrale per le app di AI. IAP intercetta tutte le richieste HTTPS destinate al gateway e controlla l'identità e le autorizzazioni del chiamante. IAP consente solo alle richieste autenticate e autorizzate di passare al workload del servizio di backend. IAP sul bilanciatore del carico del gateway protegge solo il traffico proveniente dall'esterno del cluster. La comunicazione all'interno del cluster non passa attraverso IAP.

Per accedere alle app di AI ospitate su GKE e protette da IAP, alle identità utente principali deve essere concesso il ruolo IAM Utente app web con protezione IAP (roles/iap.httpsResourceAccessor) sulla risorsa del servizio di backend protetto da IAP. Ti consigliamo di configurare un account di servizio personalizzato come identità per gli agenti di cui è stato eseguito il deployment. L'utilizzo di un account di servizio personalizzato ti consente di assegnare le autorizzazioni in modo più preciso in base al principio del privilegio minimo.

Concedi il ruolo IAM Utente app web con protezione IAP direttamente ai service account degli agenti autorizzati ad accedere ad altri agenti e strumenti ospitati sul servizio GKE scelto come target dalla risorsa personalizzata GCPBackendPolicy (o BackendConfig per Ingress). Per consentire l'accesso alle app Gemini Enterprise, concedi le autorizzazioni associando il ruolo IAM Service account Discovery Engine (roles/discoveryengine.serviceAgent) per il tuo progetto Gemini Enterprise.

Controlli di servizio VPC

I Controlli di servizio VPC mitigano i rischi di esfiltrazione di dati controllando rigorosamente l'accesso alle API di Google. Ti consigliamo di eseguire il deployment di un unico macroperimetro che includa tutti i servizi supportati. Questo approccio fornisce la difesa più efficace contro l'esfiltrazione. Per garantire un'applicazione coerente delle policy per le architetture VPC condiviso, è fondamentale includere sia il progetto host sia tutti i progetti di servizio associati all'interno dello stesso perimetro di servizio.

Per proteggere l'interazione tra Gemini Enterprise e Cloud Run oltre i confini del progetto, tieni presente i seguenti consigli:

  • Esegui il deployment di un unico perimetro dei Controlli di servizio VPC che comprenda sia i progetti Gemini Enterprise sia quelli Cloud Run.
  • Aggiungi tutti i servizi supportati dai Controlli di servizio VPC all'elenco dei servizi limitati. Questo approccio aiuta a prevenire modifiche amministrative non autorizzate.
  • Applica le impostazioni di ingress e autorizzazione interne per bloccare tutti gli accessi a internet pubblico ai tuoi servizi Cloud Run.

I servizi Cloud Run sono protetti da IAM. I chiamanti devono essere autenticati e devono disporre del ruolo IAM Cloud Run Invoker (roles/run.invoker) sul servizio di destinazione. Il ruolo viene controllato convalidando un token dall'intestazione Authorization (o dall'intestazione X-Serverless-Authorization quando Gemini Enterprise chiama un URL .run.app predefinito). Per chiamare correttamente il servizio Cloud Run, ai service account, come quelli utilizzati da Gemini Enterprise, deve essere concesso anche il ruolo Cloud Run Invoker.

Quando Gemini Enterprise e Cloud Run vengono distribuiti in progetti diversi, è necessario un perimetro dei Controlli di servizio VPC per impostare il traffico in entrata di Cloud Run su Interno. Senza questo perimetro, le chiamate tra progetti da Gemini Enterprise vengono trattate come traffico esterno, il che ti costringe a impostare il traffico in entrata di Cloud Run su Tutti, lasciando il servizio esposto alla rete internet pubblica.

  • Il traffico in entrata di Cloud Run all è supportato quando entrambe le seguenti condizioni sono vere:
    • I Controlli di servizio VPC non sono abilitati.
    • Cloud Run e Gemini Enterprise non si trovano nello stesso progetto.
  • Per tutte le altre configurazioni è supportato solo il traffico in entrata di Cloud Run internal.

Ulteriori considerazioni sui Controlli di servizio VPC

Quando viene eseguito il deployment di Cloud Run all'interno di un perimetro dei Controlli di servizio VPC, ti consigliamo di implementare i seguenti controlli di policy per garantire una protezione completa:

  • Limita le impostazioni del traffico in entrata consentite: impedisci agli sviluppatori di eseguire accidentalmente il deployment di endpoint rivolti al pubblico impostando il vincolo della policy dell'organizzazione run.allowedIngress. Questo vincolo si applica solo ai nuovi deployment. I deployment precedenti potrebbero non essere conformi. Ti consigliamo di controllare tutti i servizi Cloud Run esistenti all'interno del perimetro e di eseguire nuovamente il deployment o aggiornare quelli che non soddisfano le impostazioni di traffico in entrata e in uscita richieste.
    • Per consentire solo le richieste interne, imposta il valore su internal.
    • Per consentire le richieste tramite un bilanciatore del carico delle applicazioni esterno, imposta il valore su internal-and-cloud-load-balancing.
  • Limita le impostazioni di traffico VPC in uscita consentite: per instradare tutte le richieste in uscita tramite il VPC in modo che possano essere ispezionate dalle regole firewall perimetrali, imposta il valore del vincolo della policy dell'organizzazione run.allowedVPCEgress su all-traffic. Questa impostazione richiede che ogni revisione Cloud Run utilizzi il traffico VPC diretto in uscita o un connettore di accesso VPC serverless. Questo vincolo si applica solo ai nuovi deployment. I deployment precedenti potrebbero non essere conformi. Ti consigliamo di controllare tutti i servizi Cloud Run esistenti all'interno del perimetro e di eseguire nuovamente il deployment o aggiornare quelli che non soddisfano le impostazioni di traffico in entrata e in uscita richieste.
  • Colloca immagini container e servizi: il repository Artifact Registry che contiene le immagini container deve trovarsi nello stesso perimetro del servizio Cloud Run. Il pull delle immagini tra perimetri viene bloccato automaticamente, a meno che non vengano stabilite regole esplicite per il traffico in entrata e in uscita.
  • Gestisci i livelli di accesso: le regole delle policy in entrata e i livelli di accesso dei Controlli di servizio VPC che si basano sulle identità delle entità IAM non sono supportati per le chiamate di Cloud Run. Devi invece gestire l'accesso con criteri basati sulla rete o livelli di accesso basati sul dispositivo.

Model Armor

Model Armor è un servizio basato su API che fornisce una maggiore sicurezza per le app di AI. Gli agenti AI interagiscono con Model Armor effettuando chiamate per sanificare i prompt degli utenti prima che vengano inviati a un LLM e per sanificare le risposte del modello prima che vengano restituite all'utente. Model Armor analizza attivamente i prompt e le risposte degli LLM, fornendo un importante punto di ispezione per rilevare i rischi emergenti e un punto di controllo per l'implementazione di standard di AI responsabile. Ti consigliamo di utilizzare Model Armor per garantire la conformità ai requisiti di residenza dei dati e alle normative legali sulla sovranità dei dati. Per utilizzare Model Armor all'interno di un perimetro dei Controlli di servizio VPC, devi configurare un endpoint Private Service Connect per l'endpoint regionale di Model Armor all'interno della tua rete VPC.

Model Armor è un servizio regionale a cui si accede privatamente tramite gli endpoint Private Service Connect regionali nella rete VPC. Ad esempio, il servizio us-central1 viene chiamato utilizzando l'endpoint regionale modelarmor.us-central1.rep.googleapis.com. Gli endpoint regionali contribuiscono a garantire la residenza dei dati.

Per abilitare l'accesso per gli agenti, configura i seguenti componenti in ogni regione in cui è richiesto il servizio Model Armor:

  1. Crea o identifica una subnet RFC 1918 nella regione della rete VPC in cui si trova il servizio Model Armor.
  2. Crea un endpoint a livello di regione nella subnet RFC 1918.
  3. Crea una zona privata di Cloud DNS e un record per il nome host dell'endpoint regionale di Model Armor (ad esempio modelarmor.us-central1.rep.googleapis.com) che si risolve nell'indirizzo IP dell'endpoint regionale.
  4. Per l'interoperabilità di Agent Runtime, stabilisci il peering DNS da Agent Runtime alla zona privata Cloud DNS associata alla tua rete VPC. Quando gli agenti effettuano richieste a Model Armor, Cloud DNS risolve le richieste del nome host nell'indirizzo IP dell'endpoint regionale di Private Service Connect nella rete VPC. Questo passaggio non è obbligatorio per gli agenti ospitati in Cloud Run e GKE.

Per integrare Gemini Enterprise con Model Armor, crea un template Model Armor nello stesso progetto di Gemini Enterprise. La posizione del modello e dell'app Gemini Enterprise deve essere la stessa.

Per saperne di più sull'attivazione di Model Armor, consulta queste risorse:

Cloud Armor

Cloud Armor è un servizio di sicurezza di rete distribuito che protegge le app e i servizi dietro i bilanciatori del carico prima che le richieste raggiungano i runtime servizio di backend. I workload degli agenti AI comportano volumi elevati di comunicazioni tra servizi che utilizzano chiamate A2A, MCP e API. La protezione di Cloud Armor fornisce ulteriori livelli di resilienza nella progettazione della sicurezza con limitazione di frequenza, screening WAF e regole personalizzate conformi alle richieste degli agenti previste. Collegando le policy di sicurezza di Cloud Armor ai servizi di backend del bilanciatore del carico delle applicazioni, il traffico può essere filtrato per individuare richieste dannose e controllato con limitazione di frequenza, mentre gli attacchi DDoS possono essere mitigati.

Cloud Armor può essere implementato in un'architettura di rete di agenti nei seguenti scenari:

  • Cloud Run con bilanciatore del carico delle applicazioni interno: proteggi gli agenti e gli strumenti eseguiti su Cloud Run utilizzando un bilanciatore del carico delle applicazioni interno con backend NEG serverless. Applica le policy di sicurezza del backend al NEG serverless per applicare le regole WAF per il traffico interno e la limitazione di frequenza. Per controllare le comunicazioni degli agenti, puoi definire regole personalizzate aggiuntive in base agli indirizzi IP e alle intestazioni.
  • Gateway: proteggi gli agenti e gli strumenti eseguiti su GKE utilizzando una definizione di risorsa Gateway per un bilanciatore del carico delle applicazioni esterno globale o regionale con backend NEG di zona. Utilizza l'API Kubernetes Gateway per applicare la risorsa GCPBackendPolicy con la policy di sicurezza Cloud Armor definita. Se utilizzi un bilanciatore del carico delle applicazioni esterno regionale, Cloud Armor supporta le policy di sicurezza del backend con regole WAF, controlli basati su indirizzi IP e geolocalizzazione e limitazione di frequenza. I bilanciatori del carico delle applicazioni esterni globali supportano le policy di sicurezza del backend e altre policy di sicurezza perimetrale con Google Cloud Armor Adaptive Protection e Google Threat Intelligence.

Secure Web Proxy

Secure Web Proxy è un servizio gestito a livello di regione di cui viene eseguito il deployment all'interno della rete VPC per filtrare il traffico HTTP/S proveniente dalla rete VPC o da qualsiasi rete connessa. Funge da proxy centralizzato e punto di applicazione della sicurezza per fornire controllo e visibilità granulari per il traffico internet in uscita. Funge anche da proxy esplicito per le comunicazioni dei servizi interni.

Secure Web Proxy supporta tre modalità di deployment: modalità di routing del proxy esplicito, modalità di collegamento del servizio Private Service Connect e modalità next hop. Ti consigliamo di utilizzare Secure Web Proxy in modalità di routing proxy esplicito, che è l'argomento di questo documento. In questa modalità, i client HTTP devono essere configurati esplicitamente per puntare direttamente all'indirizzo IP o al nome host di Secure Web Proxy.

Per eseguire il deployment di Secure Web Proxy nella tua rete VPC, devi configurare una subnet di frontend e una subnet solo proxy. Secure Web Proxy è un servizio completamente gestito. Quando viene eseguito il deployment di Secure Web Proxy, viene eseguito automaticamente il deployment e la configurazione di router Cloud e Cloud NAT nella tua rete VPC per un'integrazione specifica con la risorsa proxy. Questa configurazione impone che tutte le richieste in uscita passino attraverso Secure Web Proxy prima di uscire su internet.

L'utilizzo di Secure Web Proxy come proxy esplicito supporta le richieste degli agenti provenienti dalle interfacce Private Service Connect di Agent Runtime, dal traffico in uscita VPC diretto di Cloud Run e dai cluster GKE VPC nativi. Quando gli agenti inviano richieste a Secure Web Proxy utilizzando il metodo HTTP CONNECT, il traffico della sessione TCP viene sottoposto a tunneling verso il proxy in cui vengono applicate le regole delle policy di sicurezza. Se il traffico è consentito, Secure Web Proxy lo invia al traffico in uscita verso internet controllato o alle destinazioni della rete privata instradabili dalla rete VPC.

Routing proxy esplicito

Il traffico in uscita di Agent Runtime richiede l'utilizzo di una configurazione proxy esplicita per consentire agli agenti di raggiungere destinazioni internet o intervalli di indirizzi IP non instradabili nella rete VPC. Per l'interoperabilità di Agent Runtime, ti consigliamo di configurare la risorsa Secure Web Proxy con un indirizzo IP RFC 1918 di una subnet di frontend nella rete VPC. Con questa configurazione, Secure Web Proxy diventa direttamente raggiungibile dal runtime dell'agente. Può quindi fungere da proxy per qualsiasi connessione a destinazioni con indirizzi IP non instradabili che si trovano nella rete VPC o nelle reti connesse.

Per supportare l'utilizzo di Secure Web Proxy da parte della piattaforma di hosting degli agenti in modalità di routing esplicito, configura queste risorse di networking:

  1. Crea o identifica una subnet RFC 1918 nella rete VPC per ospitare la risorsa Secure Web Proxy.
  2. Crea un record Cloud DNS per il nome host di Secure Web Proxy (ad esempio swp.example.com) che si risolve nell'indirizzo IP della risorsa Secure Web Proxy.
  3. Per l'interoperabilità di Agent Runtime, stabilisci il peering DNS da Agent Runtime alla zona privata Cloud DNS associata alla tua rete VPC. Quando gli agenti effettuano richieste a Secure Web Proxy, Cloud DNS risolve le richieste del nome host nell'indirizzo IP della risorsa Secure Web Proxy nella rete VPC. Questo passaggio non è obbligatorio per gli agenti ospitati in Cloud Run e GKE.

Impostazioni del proxy dell'agente

Il modo standard per configurare le app dell'agente in modo che utilizzino un proxy HTTP(S) è impostare queste variabili di ambiente:

  • HTTP_PROXY: l'URL del server proxy esplicito per il traffico HTTP (ad esempio, http://swp.example.com:8888). Questa configurazione utilizza il metodo HTTP CONNECT dal client al proxy. Anche se è specificato HTTP, la crittografia TLS viene mantenuta end-to-end tramite il proxy dall'Agent Runtime all'endpoint di destinazione.
  • HTTPS_PROXY: l'URL del server proxy esplicito per il traffico HTTPS (ad esempio, https://swp.example.com:8888). Come l'impostazione HTTP_PROXY, l'impostazione HTTPS_PROXY utilizza TLS per impostazione predefinita. Tuttavia, puoi fornire un ulteriore livello di crittografia attivando la tua crittografia TLS oltre a quella predefinita. Per saperne di più, consulta Certificate Authority Service.
  • NO_PROXY: un elenco separato da virgole di nomi host o indirizzi IP che non devono passare attraverso il proxy. Ad esempio, se aggiungi metadata.google.internal e 169.254.169.254 all'elenco NO_PROXY, i workload possono accedere direttamente al servizio di metadati per l'autenticazione e l'autorizzazione alle API e ai servizi Google.

Quando utilizzi l'argomento env_vars per impostare le variabili durante il deployment, queste diventano disponibili nell'ambiente di Agent Runtime (ad esempio, quando utilizzi os.environ in Python). La maggior parte delle librerie client HTTP standard rileva e utilizza automaticamente queste variabili di ambiente per instradare il traffico attraverso il proxy specificato. Questo approccio è comune per le app Python e le librerie client HTTP come requests. Quando esegui il deployment degli agenti, definisci le variabili di ambiente per l'utilizzo di Secure Web Proxy per tutti i domini privati che gli agenti devono raggiungere. Assicurati che anche tutte le destinazioni di dominio privato siano incluse in Cloud DNS.

L'esempio seguente mostra il deployment di un proxy Agent Runtime da un oggetto agent:

import agentplatform

client = agentplatform.Client(
    project="PROJECT_ID",
    location="LOCATION",
)

## 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 = client.runtimes.create(
    agent=local_agent,
    config={
        "display_name": "Example agent using proxy",
        "env_vars": env_vars,
        ## ... other configs
    },
)

Cloud Run supporta l'impostazione delle variabili di ambiente a livello di revisione del servizio. Questo approccio esegue l'override di tutte le variabili di ambiente con lo stesso nome impostate all'interno dell'immagine container. Questo approccio è utile per impostare parametri operativi come le variabili proxy all'avvio delle istanze di servizio.

L'esempio seguente mostra il comando per impostare le variabili di ambiente quando esegui il deployment di un servizio 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"

Per implementare una configurazione del proxy esplicito nei pod GKE, definisci una risorsa ConfigMap che specifica le variabili del 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"

Per applicare le chiavi ConfigMap ai pod, utilizza il campo envFrom nel manifest del container. Questa specifica inserisce le variabili di ambiente nel container in fase di runtime.

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

Servizio CA

Certificate Authority Service è necessario quando Secure Web Proxy o Cloud NGFW sono configurati per l'ispezione TLS. Quando l'ispezione TLS è abilitata e la destinazione di un workload utilizza TLS, Certificate Authority Service crea e firma un certificato per quella destinazione. Quando il traffico criptato per la destinazione reale arriva a Secure Web Proxy o Cloud NGFW, il pacchetto viene decriptato, ispezionato e vengono applicate le policy. Se le policy consentono il pacchetto, il servizio lo cripta nuovamente per la destinazione finale. Puoi anche utilizzare CA Service per fornire certificati ad altri servizi gestiti da Google.

CA Service è un servizio gestito. Dopo la configurazione di CA Service, questo gestisce la firma dei certificati foglia fino alla scadenza del certificato CA principale. I certificati CA radice devono essere aggiornati per garantire che non scadano.

CA Service supporta queste funzionalità per consentire l'ispezione del traffico e la gestione dei certificati su larga fare lo scale in un'architettura AI multi-agente:

  • Ispezione TLS: per l'ispezione TLS completa è necessario l'utilizzo di una CA privata. Per decriptare e analizzare completamente i payload HTTPS, il dispositivo proxy intermedio (Secure Web Proxy o Cloud NGFW) deve terminare la sessione TLS con il client. Il proxy deve presentare un certificato valido che il client accetta come attendibile per il dominio richiesto.

    CA Service può generare e firmare dinamicamente un certificato di impersonificazione specifico per il sito richiesto. Quando il client ha il certificato CA radice privato installato nel suo archivio di attendibilità, accetta questo certificato creato in modo dinamico come valido. Il client considera attendibile il certificato inviato dal proxy, quindi invia la richiesta. Il proxy termina la sessione TLS, decripta il pacchetto, ne ispeziona i contenuti e applica le policy.

  • Distribuzione dei certificati: le risorse client interne, come gli agenti AI eseguiti su Agent Runtime, Cloud Run o GKE, devono aggiungere il certificato CA radice privato ai propri archivi di attendibilità locali. Archiviando la chiave pubblica del certificato CA radice in Secret Manager, gli agenti AI possono estrarre il certificato all'avvio e aggiungerlo all'archivio di attendibilità del sistema.

    Le risorse server interne, come i bilanciatori del carico delle applicazioni interni, richiedono certificati emessi dalla CA privata per fungere da endpoint server attendibili e terminare le sessioni TLS client. I bilanciatori del carico delle applicazioni si integrano con le configurazioni di emissione di Certificate Manager per automatizzare la firma della richiesta di certificato da parte di Certificate Authority Service e il deployment nel bilanciatore del carico.

Per saperne di più sulle operazioni relative ai certificati, consulta queste risorse:

Sicurezza della connessione A2A

Gli agenti principali comunicano con una vasta gamma di subagenti e server MCP di cui è stato eseguito il deployment su varie piattaforme di hosting di runtime. Ogni ambiente introduce requisiti di networking e sicurezza unici che devono essere astratti dal livello A2A o MCP.

Il seguente diagramma mostra i componenti e i possibili percorsi di connessione supportati da questa guida alla progettazione:

Modelli di connettività Agent2Agent (A2A) tra diverse piattaforme di hosting, tra cui GKE, Cloud Run e Agent Runtime, e connessioni ai server MCP e a internet.

Il diagramma precedente riassume queste possibilità di connessione:

  • Gli utenti interagiscono con il sistema agentico tramite un'app Gemini Enterprise.
  • L'app Gemini Enterprise utilizza l'infrastruttura Google per connettersi a un agente root eseguito in GKE, Cloud Run o Agent Runtime.
  • L'app Gemini Enterprise e gli agenti principali utilizzano l'infrastruttura Google per connettersi a Model Armor e all'LLM Gemini su Agent Platform.
  • Gli agenti root possono utilizzare l'infrastruttura Google per connettersi ai subagenti eseguiti in Cloud Run o Agent Runtime.
  • Gli agenti root possono utilizzare indirizzi IP privati per connettersi ai subagenti eseguiti in Agent Runtime, Cloud Run e GKE. Queste connessioni devono essere instradate tramite una rete VPC.
  • Sia gli agenti principali che i subagenti possono connettersi ai server MCP eseguiti su Cloud Run o GKE. Gli agenti che si connettono ai server MCP possono utilizzare l'infrastruttura Google o una rete VPC. I server MCP forniscono l'accesso a strumenti ospitati inGoogle Cloud, on-premise, in un altro cloud o su internet.
  • I servizi ospitati su internet sono raggiungibili direttamente tramite Secure Web Proxy.

Le sezioni seguenti forniscono risorse per i percorsi dei dati di runtime e i controlli di sicurezza necessari per interazioni A2A sicure. Queste informazioni fungono da standard architetturale per stabilire la connettività privata e implementare le difese multilivello necessarie per proteggere il percorso dei dati end-to-end tra gli agenti.

Agente di origine GKE

La tabella seguente fornisce risorse per aiutarti a proteggere il traffico quando GKE è l'agente di origine. Questo traffico viaggia attraverso la rete VPC che ospita il cluster GKE.

Agente di destinazione (percorso dei dati) Controllo di sicurezza
Agent Runtime (interno)
Cloud Run (interno)
Cloud Run (Private Service Connect per le API di Google)
Accesso a Cloud Run (NEG serverless)
GKE
Internet tramite rete VPC

Agente di origine Agent Runtime (interno)

La tabella seguente fornisce risorse per aiutarti a proteggere il traffico quando l'agente di runtime è l'agente di origine e il traffico viaggia direttamente sull'infrastruttura Google. In questi percorsi non è coinvolta alcuna rete VPC.

Agente di destinazione (percorso dei dati) Controllo di sicurezza
Agent Runtime (interno)
Cloud Run (interno)

Agente di origine Agent Runtime (interfaccia Private Service Connect)

La tabella seguente fornisce risorse per aiutarti a proteggere il traffico quando Agent Runtime è l'agente di origine e il traffico utilizza un'interfaccia Private Service Connect per viaggiare attraverso una rete VPC.

Agente di destinazione (percorso dei dati) Controllo di sicurezza
Cloud Run (Private Service Connect per le API di Google)
Accesso a Cloud Run (NEG serverless)
GKE
Internet tramite rete VPC

Agente di origine Cloud Run (interno)

La tabella seguente fornisce risorse per aiutarti a proteggere il traffico quando Cloud Run è l'agente di origine e il traffico viaggia direttamente sull'infrastruttura Google. In questi percorsi non è coinvolta alcuna rete VPC.

Agente di destinazione (percorso dei dati) Controllo di sicurezza
Agent Runtime (interno)
Cloud Run (interno)

Agente di origine Cloud Run (traffico VPC diretto in uscita)

La tabella seguente fornisce risorse per aiutarti a proteggere il traffico quando Cloud Run è l'agente di origine e il traffico utilizza il traffico VPC diretto in uscita per viaggiare attraverso una rete VPC.

Agente di destinazione (percorso dei dati) Controllo di sicurezza
Cloud Run (Private Service Connect per le API di Google)
Accesso a Cloud Run (NEG serverless)
GKE
Internet tramite rete VPC
Agent Runtime (Private Service Connect per le API di Google)

Sicurezza della connessione MCP

L'elenco seguente descrive le piattaforme di hosting e i controlli di difesa in profondità coinvolti nella protezione del percorso dei dati tra i runtime degli agenti e i server MCP. Per gli agenti di origine in Agent Runtime, in Cloud Run o in GKE, utilizza i seguenti controlli di sicurezza a seconda del server MCP di destinazione:

  • Internet:
    • Controlli di servizio VPC
    • Model Armor
    • Cloud NGFW
    • Secure Web Proxy
  • Google MCP:
    • Controlli di servizio VPC
    • Model Armor

Passaggi successivi

Collaboratori

Autori:

  • Deepak Michael | Networking Specialist Customer Engineer
  • Michael Larson | Customer Engineer, Networking Specialist
  • Victor Moreno | Product Manager, Cloud Networking

Altri collaboratori: