Pattern di networking privato multi-agente in Google Cloud

Last reviewed 2026-04-16 UTC

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

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

Nella progettazione descritta in questo documento, gli agenti comunicano con altri agenti e con gli strumenti utilizzando il protocollo Agent2Agent (A2A) e il protocollo Model Context (MCP). Le comunicazioni vengono rese private instradandole tramite una rete VPC. Per spostare il traffico all'interno e all'esterno della rete VPC, questo design utilizza una combinazione di endpoint Private Service Connect, interfacce Private Service Connect e uscita VPC diretta di Cloud Run. Cloud Next Generation Firewall (Cloud NGFW) gestisce il traffico che passa attraverso la rete VPC. Livelli di sicurezza aggiuntivi forniscono un'uscita controllata da internet utilizzando Secure Web Proxy e forniscono criteri 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. Google Cloud

Pattern di progettazione multi-agente

Un'app Gemini Enterprise multi-agente richiede un agente personalizzato che funga da orchestratore o agente root per le connessioni a strumenti e subagenti. Per implementare connessioni private a strumenti e subagenti ospitati in Google Cloud o on-premise, la progettazione utilizza una rete VPC con indirizzi IP privati. L'agente principale è ospitato nell'infrastruttura di Google, utilizzando Agent Engine, Cloud Run o GKE. Il pattern di progettazione multi-agente mette in evidenza 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 funzionalità di agenti personalizzati. Gli agenti root personalizzati vengono registrati con Gemini Enterprise e sono resi disponibili nelle app per gli utenti finali. L'agente root personalizzato funge da orchestratore del flusso di lavoro di primo livello e delega le attività specializzate ai subagenti. Questa architettura utilizza agenti root personalizzati ospitati su Vertex AI Agent Engine, Cloud Run o GKE.
  2. Agenti root che interagiscono con subagenti e strumenti. Il cuore 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 root a subagenti e strumenti tramite la rete VPC. Utilizzando il networking VPC per questa parte dell'architettura, gli agenti possono utilizzare percorsi di networking privati definiti dall'utente che espongono altri endpoint privati, controlli di sicurezza aziendali e una raggiungibilità 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 per consentire agli utenti di accedere a un'interfaccia di chat in-app e interagire con il sistema di AI multi-agente. Gli utenti possono accedere alle app Gemini Enterprise tramite internet pubblico o privatamente tramite connessioni ibride.
  • Agenti personalizzati: agenti root creati e registrati con Gemini Enterprise e ospitati su Vertex AI Agent Engine, Cloud Run o GKE. Questi agenti root fungono da orchestratori che delega le attività ai subagenti.
  • Rete VPC: una risorsa che controlli per fornire agli agenti la connettività di rete IP a endpoint privati e una più ampia 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 flusso di lavoro dell'agente principale. I subagenti comunicano utilizzando il protocollo A2A, che consente l'interoperabilità tra gli agenti indipendentemente dal linguaggio di programmazione e dall'ambiente di runtime.
  • Strumenti: sistemi remoti che espongono servizi come API, origini dati e funzioni del workflow. Questi strumenti recuperano i dati ed eseguono azioni o transazioni per gli agenti. Gli strumenti sono esterni agli agenti e questi si connettono e interagiscono con gli strumenti utilizzando la specifica MCP.

Questo pattern di progettazione multi-agente di alto livello evidenzia i componenti di rete 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, vedi Scegliere 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, Cloud Router, 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 dell'agente, tra cui Vertex AI Agent Engine, Cloud Run, GKE, Gemini Enterprise e bilanciatori del carico specifici per l'app.

Il VPC condiviso impone un limite chiaro tra i ruoli di amministratore di rete e sicurezza e gli sviluppatori 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 i criteri firewall.
  • Gli sviluppatori di app AI creano agenti nei progetti di servizio collegati senza disporre delle autorizzazioni per modificare l'infrastruttura di rete sottostante.

Quando centralizzi le implementazioni di rete e sicurezza all'interno di un progetto host, crei un unico punto di gestione per la comunicazione da agente ad agente e da agente a servizio. Questo design semplifica l'applicazione delle norme di sicurezza in molti progetti di servizio 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 alla VPC condiviso la raggiungibilità completa delle route dell'hub NCC e la connettività ai punti di accesso al servizio da altri spoke.

Le richieste avviate da agenti root personalizzati utilizzano una rete VPC privata e gestita dal cliente per fornire percorsi di rete sicuri a subagenti, strumenti e servizi. Il routing della rete VPC regola la raggiungibilità degli endpoint privati. Le policy 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à a quanto segue:

  • Altre reti VPC tramite peering di rete VPC, appliance multi-NIC o NCC.
  • Endpoint di Private Service Connect per accedere ai servizi del producer.
  • Servizi gestiti con indirizzi IP privati, come Cloud SQL.
  • Front-end 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, 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 ospitato al di fuori della rete VPC, ma all'interno della rete di Google. Le sezioni seguenti descrivono la configurazione della rete tra l'utente e l'app Gemini Enterprise e la rete tra l'app e gli agenti.

Chat utente con le app Gemini Enterprise

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

App Gemini Enterprise agli agenti personalizzati

Registri gli agenti personalizzati con il servizio di rilevamento di Gemini Enterprise. Quando registri un agente, Gemini Enterprise mappa il nome dell'agente a un target specifico, ovvero l' URI della risorsa Vertex AI Agent Engine 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 registro per trovare l'endpoint associato.

Quando registri un agente principale con Gemini Enterprise, puoi eseguire il deployment di questo agente ovunque come agente personalizzato. Gli agenti personalizzati su Vertex AI Agent Engine e su Cloud Run possono utilizzare percorsi di rete privati esistenti senza configurare risorse di rete 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 più sicuro, consulta la sezione Networking GKE più avanti in questo documento.

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

  • Agenti personalizzati su Vertex AI Agent Engine: l'agente di servizio Vertex AI Discovery Engine include i ruoli Vertex AI Identity and Access Management (IAM) necessari per richiamare le risorse Vertex AI Agent Engine come funzionalità integrata. Il sistema instrada le richieste effettuate al servizio API Vertex AI sulla rete Google come chiamata API interna.
  • Agenti personalizzati su Cloud Run: le app Gemini Enterprise utilizzano l'identità del service agent Vertex AI Discovery Engine per effettuare chiamate all'URL run.app stabile registrato dalla scheda dell'agente. Affinché il servizio Cloud Run dell'agente AI autorizzi 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 all'ingresso Google Front End (GFE) per Cloud Run.

  • Agenti personalizzati su GKE: le app Gemini Enterprise utilizzano l'identità dell'agente di servizio Vertex AI 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 gke-l7-regional-external-managed bilanciatore del carico o il bilanciatore del carico gke-l7-global-external-managed. Per una maggiore sicurezza, consigliamo a Gemini Enterprise di chiamare un agente A2A ospitato su GKE utilizzando Identity-Aware Proxy (IAP). Affinché IAP autorizzi 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 al 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 a subagenti e strumenti. Le piattaforme di hosting di agenti personalizzati forniscono l'interfaccia tra Gemini Enterprise e le tue reti VPC. Le piattaforme di hosting per i tuoi agenti e strumenti containerizzati sono Vertex AI Agent Engine, Cloud Run e GKE.

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

Stabilisci la connettività VPC privata tramite diversi meccanismi in base alla piattaforma di hosting dell'agente che utilizzi:

  • Agenti personalizzati su Vertex AI Agent Engine: le interfacce Private Service Connect collegano i runtime di Vertex AI Agent Engine alla rete VPC. Crea un collegamento di rete in una subnet della rete VPC e concedi a Vertex AI Agent Engine l'autorizzazione per collegarsi. Il traffico inviato da Vertex AI Agent Engine viene visualizzato nella rete VPC come se avesse origine dall'indirizzo IP della subnet dell'allegato. La rete VPC instrada quindi il traffico verso l'indirizzo IP di destinazione appropriato.
  • Agent personalizzati su Cloud Run: l'uscita VPC diretta di Cloud Run connette le istanze di servizio Cloud Run alla rete VPC. La rete VPC specificata durante il deployment di un servizio Cloud Run può provenire dal progetto di servizio Cloud Run o dal progetto host VPC condiviso. Il traffico inviato da Cloud Run viene visualizzato nella rete VPC come se avesse origine dall'indirizzo IP della subnet dell'uscita VPC diretta. 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 di uscita GKE utilizza l'indirizzo IP del pod come indirizzo IP di origine. Se configuri il masquerading, il traffico in uscita 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 ulteriori indicazioni per la gestione delle richieste in entrata e in uscita nella rete VPC per ciascuna piattaforma di hosting degli agenti. Le considerazioni sulla rete sono applicabili sia alla funzionalità dell'agente principale sia a quella del subagente.

Networking di Vertex AI Agent Engine

Questa sezione descrive il networking privato per gli agenti root e i subagenti ospitati su Vertex AI Agent Engine. Se utilizzi Vertex AI Agent Engine per ospitare l'agente principale, devi eseguire il deployment di Gemini Enterprise e Vertex AI Agent Engine nello stesso progetto.

Vertex AI Agent Engine ospita i container nell'infrastruttura Google al di fuori della tua rete VPC. Per attivare la connettività privata ad altri agenti, puoi connettere l'agente alla tua rete VPC utilizzando i seguenti metodi:

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

Vertex AI Agent Engine in uscita verso la rete VPC

Vertex AI Agent Engine utilizza un progetto tenant gestito da Google per l'uscita di rete. La rete tenant fornisce connettività per gli agenti alle API di Google e per l'uscita da internet pubblico, ma non è connessa direttamente alle reti VPC del cliente per impostazione predefinita.

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

Per eseguire il deployment dell'uscita della rete VPC di Vertex AI Agent Engine, consulta queste risorse:

Per proteggere ulteriormente gli agenti e la rete VPC per l'uscita di Vertex AI Agent Engine, consulta queste sezioni più avanti in questo documento:

Ingresso di Vertex AI Agent Engine dalla rete VPC

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

Gli utenti privati che eseguono query agli agenti devono risolvere il nome host dell'endpoint API Vertex AI 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 googleapis.com risolve le richieste per l'API Vertex AI. 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 a Vertex AI Agent Engine utilizzando i seguenti prodotti e funzionalità:

Considerazioni aggiuntive sulla rete di Vertex AI Agent Engine

Il traffico in uscita di Vertex AI Agent Engine che utilizza le interfacce Private Service Connect può essere instradato solo verso intervalli di indirizzi IP RFC 1918 nella rete VPC. Per intervalli di destinazione specifici non instradabili dall'uscita di Vertex AI Agent Engine, consulta Requisiti dell'intervallo IP della subnet. Per raggiungere destinazioni con intervalli di indirizzi IP non instradabili, utilizza una configurazione proxy esplicita sugli agenti e implementa risorse proxy che utilizzano un indirizzo IP instradabile nella rete VPC.

Quando Vertex AI Agent Engine viene implementato senza un'interfaccia Private Service Connect, ha accesso a internet per impostazione predefinita. Per proteggerti dall'esfiltrazione di dati, disabilita l'accesso predefinito attivando i Controlli di servizio VPC.

Quando Vertex AI Agent Engine viene implementato con un'interfaccia Private Service Connect, il traffico internet in uscita diretto viene disattivato, indipendentemente dai Controlli di servizio VPC. Se hai bisogno che l'agente acceda a una destinazione che Vertex AI Agent Engine non può raggiungere normalmente, ad esempio internet, procedi nel seguente modo:

  1. Configura Secure Web Proxy in una subnet RFC 1918 della tua rete VPC. Devi configurare il proxy in modalità di routing proxy esplicito.
  2. Crea un record Cloud DNS per il nome host di Secure Web Proxy.
  3. Configura il peering DNS per Vertex AI Agent Engine in modo da supportare la risoluzione delle query DNS dell'agente all'indirizzo privato del Secure Web Proxy nella rete VPC.
  4. Quando esegui il deployment degli agenti:
    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.

Dopo che il traffico in uscita da Vertex AI Agent Engine 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 Vertex AI Agent Engine, consulta la sezione Cloud NGFW più avanti in questo documento.

Networking Cloud Run

Questa sezione descrive il networking privato per gli agenti root e secondari ospitati su Cloud Run. Cloud Run ospita i container sull'infrastruttura Google al di fuori della tua rete VPC. Per attivare la connettività privata ad altri agenti, puoi connettere l'agente alla tua 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 di Cloud Run verso la rete VPC

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

Quando configuri l'uscita VPC diretto, esegui le seguenti operazioni:

  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 tramite la rete VPC per la 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 le 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 Cloud DNS e i nomi host pubblici.

Per informazioni su come proteggere ulteriormente gli agenti e la rete VPC per l'uscita di Cloud Run, consulta le sezioni seguenti di questo documento:

Ingresso 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 carichi di lavoro di agenti AI o strumenti. Questi endpoint vengono pubblicati dallo stesso punto di ingresso GFE che pubblica i servizi API *.googleapis.com. Cloud Run utilizza gli stessi percorsi di rete sottostanti che consentono la connettività privata per l'accesso privato Google e per Private Service Connect per le API di Google.

Gli utenti privati sulla rete VPC che eseguono query su agent 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 Google. Una zona DNS gestita privata di Cloud DNS 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 dell'ingresso di Cloud Run su Interno limita l'accesso al tuo 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 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 di servizio Cloud Run o dell'ambiente VPC condiviso viene trattato come esterno. Questo traffico include il traffico proveniente da altri servizi Google Cloud come Vertex AI Agent Engine e altri servizi Cloud Run. Per soddisfare il controllo dell'ingresso interno di Cloud Run, questo traffico deve essere instradato in modo che sembri provenire dall'interno della rete VPC del servizio di destinazione.

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

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

I bilanciatori del carico delle applicazioni interni con backend del gruppo 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 policy di autorizzazione aggiuntive.

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 di ingresso 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 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 di AI, GKE offre una piattaforma altamente personalizzabile per i controlli di rete e di sicurezza. Un sistema di AI multi-agente di cui è stato eseguito il deployment su GKE può fornire efficienza operativa su scala. Può integrarsi perfettamente con altre app Kubernetes e architetture di microservizi più grandi.

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 al di fuori della 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 scorre dall'uscita di Gemini Enterprise alla rete edge di Google, dove segue una route ottimizzata verso il bilanciatore del carico esterno GKE.

È importante proteggere l'endpoint GKE utilizzando autenticazione e autorizzazione avanzate, 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à operative per bilanciare gestione e controllo:

  • Autopilot: Google automatizza l'intera infrastruttura del cluster GKE, inclusi piano di controllo, provisioning dei nodi, protezione della sicurezza e scalabilità.
  • Standard: Google gestisce il control plane. Mantieni la piena responsabilità per le configurazioni pool di nodi, ad esempio la selezione dei tipi di macchine, la gestione delle immagini del sistema operativo e lo scaling manuale.
Rafforzamento dell'infrastruttura e del control plane
  • Cluster GKE privati: esegui il provisioning dei nodi senza indirizzi IP pubblici, il che garantisce 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, il che rafforza il control plane contro 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. Garantisce che solo gli utenti autenticati con le autorizzazioni IAM corrette possano accedere all'endpoint dell'agente. Questo approccio sposta in modo efficace 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, tra cui regole Web Application Firewall (WAF) per bloccare i payload dannosi, protezione DDoS per garantire l'uptime e limitazione di frequenza per impedire l'esaurimento del servizio.
  • Model Armor: progettato specificamente per la sicurezza degli LLM, Model Armor ispeziona e sanitizza prompt e risposte in tempo reale per impedire prompt injection ed esfiltrazione di dati.
Isolamento della rete interna
  • Policy di rete di Kubernetes: applica una comunicazione granulare con privilegi minimi tra i microservizi. Per impostazione predefinita, i criteri negano tutto il traffico a meno che tu non lo consenta esplicitamente, il che impedisce lo spostamento laterale all'interno del cluster.

Traffico in uscita di GKE verso la rete VPC

La rete VPC instrada le connessioni in uscita dagli agenti ospitati su GKE. La modalità di rete del cluster GKE predefinita è VPC nativa, 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 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. Affinché un pod agente comunichi con altre risorse VPC come bilanciatori del carico o endpoint Private Service Connect, può raggiungere la destinazione utilizzando lo stesso routing VPC standard, soggetto alle regole firewall.

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

Ingresso GKE 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 gateway di inferenza GKE. Il gateway offre funzionalità avanzate con controllo del traffico, separazione operativa delle risorse e integrazioni di sicurezza. Tuttavia, sono disponibili altre opzioni di servizio di ingresso a seconda dei requisiti di sistema.

La risorsa Gateway crea un bilanciatore del carico delle applicazioni e 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 cross-region (gke-l7-cross-regional-internal-managed-mc).

I bilanciatori del carico delle applicazioni forniscono punti di controllo della sicurezza aggiuntivi per proteggere gli agenti e gli strumenti di 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, filtri basati su indirizzi IP e dati geografici, protezione DDoS e limitazione della 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 app Gemini Enterprise, agenti personalizzati e 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 traffico dalla tua rete VPC al tuo servizio GKE, puoi proteggere questo 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 tramite la rete VPC e la superficie API. Il piano dati della rete VPC indica come gli agenti e gli strumenti si connettono in modo sicuro. La superficie API definisce quali identità e tipi di scambi di dati sono consentiti. La stratificazione dei controlli dell'accesso sia nella rete VPC che nella superficie API contribuisce a garantire una postura di sicurezza 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 dell'agente verificando ogni connessione in entrata o in uscita da e verso altri agenti e strumenti.

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

  • Cloud Next Generation Firewall Essentials: fornisce il filtraggio dei pacchetti firewall stateful. Le regole dei criteri 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 nome di dominio completo (FQDN), oggetti di geolocalizzazione e feed di Google Threat Intelligence per bloccare gli indirizzi dannosi noti.
  • Cloud Next Generation Firewall Enterprise: fornisce funzionalità di ispezione delle app (L7) con decriptografia TLS e funzionalità di 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 i criteri del firewall in base alle regole necessarie per scegliere come target la piattaforma di hosting dell'agente che hai utilizzato.

  • Vertex AI Agent Engine: gli agenti che vengono eseguiti in Vertex AI Agent Engine si connettono alla rete VPC utilizzando i collegamenti di rete Private Service Connect. Questi collegamenti fanno sì che l'interfaccia di rete dell'agente venga visualizzata all'interno di una subnet nella rete VPC. Le policy firewall di rete Cloud NGFW vengono applicate alla rete VPC. I filtri delle policy 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 in uscita VPC diretto inviano il traffico direttamente dalle istanze in esecuzione all'interno di una subnet specificata nella rete VPC. Le policy 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. I criteri 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 account di servizio. I tag sicuri vengono associati alle istanze VM che fungono da nodi GKE. Le regole firewall possono quindi indirizzare o generare traffico dai nodi con tag specifici. Le regole firewall possono anche indirizzare o originare il traffico dai nodi GKE in base all'identità del account di servizio associato al pool di nodi.

Policy in uscita di negazione 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 venga consentito solo il traffico di rete esplicitamente autorizzato, mentre tutto il resto del traffico viene bloccato per impostazione predefinita. Questa implementazione viene ottenuta strutturando le regole firewall con regole ALLOW ad alta priorità per flussi legittimi noti e una regola DENY di tipo 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 dei criteri firewall possono corrispondere in modo efficace al traffico di origine dalla subnet dell'allegato di rete di Vertex AI Agent Engine e dalla subnet dell'uscita VPC diretta di Cloud Run.

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

  • Crea policy e regole 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 direzione di 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 la comunicazione 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 dell'allegato di rete di Vertex AI Agent Engine 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 a qualsiasi destinazione (--dest-ip-ranges=0.0.0.0/0) che non corrisponde a nessuna delle regole ALLOW precedenti.

Un criterio di negazione in uscita predefinito impedisce agli agenti di AI di effettuare connessioni di rete non esplicitamente autorizzate e blocca la potenziale esfiltrazione di dati o l'accesso a siti dannosi. Il criterio limita gli agenti ospitati a comunicare solo con gli endpoint approvati, il che è fondamentale per mantenere il controllo sui carichi di lavoro autonomi.

Considerazioni aggiuntive sui criteri 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à dei livelli a pagamento:

  • Funzionalità standard di Cloud NGFW:
    • Oggetti FQDN per endpoint dinamici: gli agenti di 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 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 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 priorità più elevata (ordine di valutazione inferiore).
  • Funzionalità di Cloud NGFW Enterprise:
    • Ispezione del livello 7: per gli agenti che gestiscono dati sensibili o che sono esposti a rischi più elevati, ispeziona i payload dei pacchetti per rilevare minacce come malware, spyware ed exploit che non vengono analizzati dalle regole del firewall del 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 sono criptati.

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

IAP

IAP protegge le richieste di ingresso 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 carico di lavoro 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) nella risorsa del servizio di backend protetta 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 protetta da IAP solo direttamente agli account di servizio degli agenti autorizzati ad accedere ad altri agenti e strumenti ospitati sulla risorsa personalizzata GKE BackendConfig. Per consentire l'accesso alle app Gemini Enterprise, concedi le autorizzazioni associando il ruolo IAM Account di servizio Discovery Engine (roles/discoveryengine.serviceAgent) per il tuo progetto Gemini Enterprise.

Controlli di servizio VPC

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

Per proteggere l'interazione tra Gemini Enterprise e Cloud Run oltre i confini del progetto, prendi in considerazione i seguenti suggerimenti:

  • Esegui il deployment di un singolo perimetro dei Controlli di servizio VPC che comprenda sia i progetti Gemini Enterprise che Cloud Run.
  • Aggiungi tutti i servizi Controlli di servizio VPC supportati all'elenco dei servizi limitati. Questo approccio contribuisce a prevenire modifiche amministrative non autorizzate.
  • Applica le impostazioni di traffico in entrata e di autorizzazione interne per bloccare tutto l'accesso 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 Invoker di Cloud Run (roles/run.invoker) sul servizio di destinazione. Il ruolo viene controllato con la convalida di un token dall'intestazione Authorization. Per chiamare correttamente il servizio Cloud Run, ai service account, come quelli utilizzati da Gemini Enterprise, deve essere concesso anche il ruolo Invoker di Cloud Run.

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

  • L'ingresso Cloud Run all è supportato quando entrambe le seguenti condizioni sono vere:
    • Controlli di servizio VPC non è abilitato.
    • Cloud Run e Gemini Enterprise non si trovano nello stesso progetto.
  • Per tutte le altre configurazioni è supportato solo l'ingresso Cloud Run internal.

Ulteriori considerazioni sui Controlli di servizio VPC

Quando Cloud Run viene implementato all'interno di un perimetro di Controlli di servizio VPC, ti consigliamo di implementare le seguenti misure di protezione delle policy per garantire una protezione completa:

  • Limita le impostazioni del traffico in entrata consentito: impedisci agli sviluppatori di eseguire il deployment accidentale di endpoint pubblici impostando il vincolo della policy dell'organizzazione run.allowedIngress. Questo vincolo si applica solo ai nuovi deployment. Le implementazioni 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 in uscita VPC consentite: Per instradare tutte le richieste in uscita tramite il VPC in modo che possano essere ispezionate dalle regole firewall del perimetro, imposta il valore del vincolo di policy dell'organizzazione run.allowedVPCEgress su all-traffic. Questa impostazione richiede che ogni revisione di Cloud Run utilizzi il traffico VPC diretto in uscita o un connettore di accesso VPC serverless. Questo vincolo si applica solo ai nuovi deployment. Le implementazioni precedenti potrebbero non essere conformi. Ti consigliamo di controllare i servizi Cloud Run esistenti all'interno del perimetro e di eseguire nuovamente il deployment o aggiornare quelli che non soddisfano le impostazioni di ingresso e uscita richieste.
  • Colloca le immagini container e i servizi: il repository Artifact Registry che contiene le immagini container deve trovarsi all'interno dello stesso perimetro del servizio Cloud Run. Il pull di immagini tra perimetri diversi viene bloccato automaticamente, a meno che tu non stabilisca regole esplicite per il traffico in entrata e in uscita.
  • Gestisci i livelli di accesso: le regole dei criteri di ingresso dei Controlli di servizio VPC e i livelli di accesso che si basano sulle identità dei principal IAM non sono supportati per le chiamate 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 offre 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, il che fornisce 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 Model Armor all'interno della tua rete VPC.

Model Armor è un servizio regionale a cui si accede privatamente tramite 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 regionale nella subnet RFC 1918.
  3. Crea una zona privata Cloud DNS e un record per il nome host dell'endpoint regionale Model Armor (ad esempio modelarmor.us-central1.rep.googleapis.com) che si risolve nell'indirizzo IP dell'endpoint regionale.
  4. Per l'interoperabilità di Vertex AI Agent Engine, stabilisci il peering DNS da Vertex AI Agent Engine alla zona DNS privata di Cloud DNS associata alla tua rete VPC. Quando gli agenti effettuano richieste a Model Armor, Cloud DNS risolve le richieste di nome host nell'indirizzo IP dell'endpoint regionale 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 modello 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 della rete distribuito che protegge app e servizi dietro i bilanciatori del carico prima che le richieste raggiungano i runtime del servizio di backend. I carichi di lavoro degli agenti AI comportano volumi elevati di comunicazione tra servizi che utilizzano chiamate A2A, MCP e API. La protezione Cloud Armor fornisce ulteriori livelli di resilienza nella progettazione della sicurezza con limitazione di frequenza, screening WAF e regole personalizzate conformi alle richieste agentiche previste. Se colleghi le policy di sicurezza di Cloud Armor ai servizi di backend del bilanciatore del carico delle applicazioni, il traffico può essere filtrato per rilevare richieste dannose e controllato con limiti di frequenza e gli attacchi DDoS possono essere mitigati.

Cloud Armor può essere implementato in un'architettura di rete agente 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 policy di sicurezza di 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 a indirizzi IP e 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 i criteri di sicurezza del backend con regole WAF, controlli basati su indirizzi IP e posizione geografica e limitazione di frequenza. I bilanciatori del carico delle applicazioni esterni globali supportano le policy di sicurezza del backend e le policy di sicurezza perimetrali aggiuntive con Google Cloud Armor Adaptive Protection e Google Threat Intelligence.

Secure Web Proxy

Secure Web Proxy è un servizio gestito regionale che viene implementato all'interno della rete VPC per filtrare il traffico HTTP/S che ha origine all'interno della rete VPC o di qualsiasi rete collegata. Funge da punto di applicazione centralizzato di proxy e sicurezza per fornire controllo e visibilità granulari per il traffico internet in uscita. Funge anche da proxy esplicito per le comunicazioni interne dei servizi.

Secure Web Proxy supporta tre modalità di deployment: modalità di routing 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 principale di questo documento. In questa modalità, i client HTTP devono essere configurati in modo esplicito 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 frontend e una subnet solo proxy. Secure Web Proxy è un servizio completamente gestito. Quando viene eseguito il deployment di Secure Web Proxy, vengono automaticamente eseguiti il deployment e la configurazione di router Cloud e Cloud NAT nella rete VPC per l'integrazione specifica con la risorsa proxy. Questa configurazione impone che tutte le richieste in uscita debbano passare tramite Secure Web Proxy prima di uscire su internet.

L'utilizzo di Secure Web Proxy come proxy esplicito supporta le richieste dell'agente provenienti da interfacce Private Service Connect di Vertex AI Agent Engine, dal traffico in uscita VPC diretto di Cloud Run e dai cluster GKE nativi di VPC. Quando gli agenti inviano richieste a Secure Web Proxy utilizzando il metodo HTTP CONNECT, il traffico della sessione TCP viene indirizzato al proxy, dove vengono applicate le regole dei criteri di sicurezza. Se il traffico è consentito, Secure Web Proxy lo invia all'uscita controllata di internet o a destinazioni di rete privata instradabili dalla rete VPC.

Routing proxy esplicito

L'uscita di Vertex AI Agent Engine 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 Vertex AI Agent Engine, ti consigliamo di configurare la risorsa Secure Web Proxy con un indirizzo IP RFC 1918 da una subnet frontend nella rete VPC. Con questa configurazione, Secure Web Proxy diventa raggiungibile direttamente da Vertex AI Agent Engine. 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 in modalità di routing esplicito da parte della piattaforma di hosting degli agenti, 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 Vertex AI Agent Engine, stabilisci il peering DNS da Vertex AI Agent Engine alla zona DNS privata di Cloud DNS associata alla tua rete VPC. Quando gli agenti effettuano richieste a Secure Web Proxy, Cloud DNS risolve le richieste di 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 agent per l'utilizzo di un proxy HTTP(S) consiste nell'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 dal runtime dell'agente 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 in aggiunta a quella TLS 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 carichi di lavoro possono accedere direttamente al servizio di metadati per l'autenticazione e l'autorizzazione alle API di Google e ai servizi.

Quando utilizzi l'argomento env_vars per impostare le variabili durante il deployment, queste diventano disponibili nell'ambiente runtime dell'agente (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 tramite 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 qualsiasi dominio privato che gli agenti devono raggiungere. Assicurati che anche le destinazioni dei domini privati siano incluse in Cloud DNS.

L'esempio seguente mostra un deployment del proxy Vertex AI Agent Engine da un oggetto agente:

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

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

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

Il seguente esempio 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 proxy esplicita nei pod GKE, definisci una risorsa ConfigMap che specifica le variabili 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 i tasti 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

CA Service è necessario quando Secure Web Proxy o Cloud NGFW è configurato per l'ispezione TLS. Quando l'ispezione TLS è abilitata e la destinazione di un workload utilizza TLS, il servizio CA 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 poi vengono applicati i criteri. Se le policy consentono il pacchetto, il servizio lo crittografa nuovamente per la destinazione finale. Puoi anche utilizzare CA Service per fornire certificati ad altri servizi gestiti da Google.

CA Service è un servizio gestito. Una volta configurato, il servizio CA gestisce la firma dei certificati foglia fino alla scadenza del certificato CA radice. I certificati CA radice devono essere aggiornati per evitare che 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: l'utilizzo di una CA privata è necessario per l'ispezione TLS completa. 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.

    Il servizio CA può generare e firmare dinamicamente un certificato di rappresentazione specifico per il sito richiesto. Quando il client ha il certificato CA radice privato installato nel proprio archivio di attendibilità, accetta questo certificato creato dinamicamente come valido. Il client considera attendibile il certificato inviato dal proxy, quindi invia la richiesta. Il proxy termina la sessione TLS, decripta il pacchetto, ispeziona i contenuti e poi applica i criteri.

  • Distribuzione dei certificati: le risorse client interne come gli agenti AI che vengono eseguiti su Vertex AI Agent Engine, Cloud Run o GKE richiedono l'aggiunta del certificato CA radice privato ai loro archivi attendibili locali. Se memorizzi 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 del server interno, come i bilanciatori del carico delle applicazioni interni, richiedono certificati emessi dalla CA privata per fungere da endpoint del server attendibili e terminare le sessioni TLS del 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 del servizio CA e il relativo deployment nel bilanciatore del carico.

Per ulteriori informazioni sulle operazioni sui certificati, consulta queste risorse:

Sicurezza della connessione A2A

Gli agenti root comunicano con una vasta gamma di subagenti e server MCP distribuiti su varie piattaforme di hosting di runtime. Ogni ambiente introduce requisiti di rete e di 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:

Pattern di connettività Agent2Agent (A2A) tra diverse piattaforme di hosting, tra cui GKE, Cloud Run e Vertex AI Agent Engine, e connessioni a 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 Vertex AI Agent Engine.
  • L'app Gemini Enterprise e gli agenti root utilizzano l'infrastruttura Google per connettersi a Model Armor e al LLM Gemini su Vertex AI.
  • Gli agenti root possono utilizzare l'infrastruttura Google per connettersi agli agenti secondari che vengono eseguiti in Cloud Run o Vertex AI Agent Engine.
  • Gli agenti root possono utilizzare indirizzi IP privati per connettersi agli agenti secondari in esecuzione in Vertex AI Agent Engine, Cloud Run e GKE. Queste connessioni devono essere instradate tramite una rete VPC.
  • Gli agenti root e secondari 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 in Google 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 passa attraverso la rete VPC che ospita il cluster GKE.

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

Agente di origine Vertex AI Agent Engine (interno)

La tabella seguente fornisce risorse per proteggere il traffico quando Vertex AI Agent Engine è l'agente di origine e il traffico transita direttamente sull'infrastruttura Google. In questi percorsi non è coinvolta alcuna rete VPC.

Agente di destinazione (percorso dati) Controllo di sicurezza
Vertex AI Agent Engine (interno)
Cloud Run (interno)

Agente di origine Vertex AI Agent Engine (interfaccia Private Service Connect)

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

Agente di destinazione (percorso dati) Controllo di sicurezza
Cloud Run (Private Service Connect GoogleAPIs)
Accesso a Cloud Run (NEG serverless)
GKE
Internet tramite la 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 transita direttamente sull'infrastruttura Google. In questi percorsi non è coinvolta alcuna rete VPC.

Agente di destinazione (percorso dati) Controllo di sicurezza
Vertex AI Agent Engine (interno)
Cloud Run (interno)

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

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

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

Sicurezza della connessione MCP

Il seguente elenco descrive le piattaforme di hosting e i controlli di difesa in profondità che sono coinvolti nella protezione del percorso dei dati tra i runtime dell'agente e i server MCP. Per gli agenti di origine in Vertex AI Agent Engine, 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: