Utilizza il gateway GKE come Agent Gateway in entrata

Quando ospiti agenti AI autonomi o server Model Context Protocol (MCP) nei tuoi cluster Google Kubernetes Engine (GKE), devi proteggere le connessioni in entrata da client esterni, CLI per sviluppatori e altri servizi. Poiché gli agenti AI determinano i loro percorsi di esecuzione in modo dinamico, i firewall di rete standard di livello 4 non possono proteggerli completamente. Utilizzando l'API gateway GKE per eseguire il deployment di un bilanciatore del carico delle applicazioni regionale, puoi gestire questo traffico client-to-agent (in entrata) e applicare guardrail di sicurezza specifici per l'AI prima che le richieste raggiungano i tuoi workload.

Se sei un amministratore della piattaforma o un security engineer che gestisce il networking di GKE, puoi utilizzare questa architettura per esporre gli agenti autogestiti in modo sicuro.

Perché utilizzare Agent Gateway per il traffico in entrata?

I microservizi standard si basano su dipendenze statiche e prevedibili. Tuttavia, gli agenti AI determinano i loro percorsi di esecuzione in modo dinamico in base ai prompt degli utenti. Per proteggere questi pattern di interazione imprevedibili, puoi convertire un gateway GKE standard in un Agent Gateway per ottenere quanto segue:

  • Applica l'autorizzazione composta: convalida sia l'identità del servizio chiamante sia il contesto semantico del payload della richiesta all'edge della rete.
  • Disaccoppia la sicurezza dal codice dell'agente: applica rigide policy di mutual TLS (mTLS) e autorizzazione senza richiedere agli sviluppatori di AI di creare una logica di sicurezza complessa nelle loro applicazioni degli agenti.
  • Sanifica automaticamente i prompt: esamina i prompt in entrata per rilevare attacchi di injection o contenuti dannosi prima che raggiungano il motore di ragionamento dell'agente.

Come funziona Agent Governance in entrata su GKE

Per gestire il traffico in entrata verso i tuoi agenti, combina le risorse standard dell'API Gateway GKE con le policy di governance di Agent Platform:

  • Gateway GKE: esegui il deployment di una risorsa Gateway standard (configurata con la GatewayClass gke-l7-regional-external-managed o gke-l7-rilb) per eseguire il provisioning di un bilanciatore del carico HTTP(S) regionale come punto di ingresso della rete.
  • Targeting di Agent Gateway: crea una risorsa personalizzata GCPAgentGateway che ha come target la risorsa Gateway, convertendo il bilanciatore del carico in un Agent Gateway gestito.
  • Controllo di identità e accessi: applica una risorsa personalizzata GCPAuthzPolicy per applicare i controlli degli accessi basati sull'identità di livello 7. Puoi verificare l'ID SPIFFE del client chiamante e limitare l'accesso a metodi MCP o nomi di strumenti specifici (come tools/list o tools/call).
  • Sicurezza dei contenuti e autorizzazione personalizzata: collega una risorsa personalizzata Service Extension Binding al tuo GCPAgentGateway per instradare i prompt in entrata e le risposte in uscita tramite Cloud de Confiance by S3NSModel Armor per bloccare gli attacchi di prompt injection o per delegare le decisioni di autorizzazione a un provider di identità (IDP) personalizzato.

Prerequisiti

Prima di poter configurare un Agent Gateway in entrata, il tuo ambiente GKE deve soddisfare i seguenti requisiti:

  • Versione del cluster GKE: il cluster deve eseguire GKE versione 1.37.1-gke.1697000 o successiva.
  • API Gateway: devi abilitare l'API gateway GKE nel tuo cluster.
  • Identità dell'agente: devi assegnare un'identità SPIFFE crittografica ai workload dell'agente in modo che il gateway possa valutare le policy basate sull'identità. Per scoprire come assegnare queste identità ai tuoi pod, consulta Informazioni su Agent Identity per GKE.
  • Agent Registry: devi registrare i deployment degli agenti in modo che Agent Registry possa rilevare i workload e sincronizzare i relativi metadati. In questo modo, Registry può rilevare i workload e sincronizzare i relativi metadati. Per registrarli, aggiungi l'etichetta registry.gke.io/functional-type: "AGENT" ai tuoi deployment.

Passaggi successivi