Padrões de rede particular multiagente no Google Cloud

Last reviewed 2026-11-09 UTC

Este documento fornece orientações para ajudar você a projetar uma infraestrutura de rede privada que ofereça suporte a um app do Gemini Enterprise multiagente e acessível publicamente, com conexões privadas entre agentes, subagentes e ferramentas. O design de rede oferece conexões particulares para agentes hospedados no Agent Runtime na Gemini Enterprise Agent Platform, no Cloud Run, no Google Kubernetes Engine (GKE), em data centers locais ou em outras nuvens. O design também é compatível com a conectividade com agentes executados em locais da Internet.

Os sistemas de IA multiagente geralmente envolvem dados confidenciais ou proprietários da organização. A rede privada permite evitar a exposição desse tráfego à Internet pública. Esse design usa a infraestrutura de rede do Google Cloud , recursos de rede de nuvem privada virtual (VPC) e conectividade privada com ambientes locais ou redes entre nuvens.

No design descrito neste documento, os agentes se comunicam com outros agentes e com ferramentas usando o protocolo Agent2Agent (A2A) e o Protocolo de Contexto de Modelo (MCP). As comunicações são privadas porque são roteadas por uma rede VPC. Para mover o tráfego para dentro e para fora da rede VPC, esse design usa uma combinação de endpoints do Private Service Connect, interfaces do Private Service Connect e saída de VPC direta do Cloud Run. O Cloud Next Generation Firewall (Cloud NGFW) controla o tráfego que passa pela rede VPC. Camadas de segurança adicionais fornecem saída de dados para a internet controlada usando o Secure Web Proxy e fornecem políticas de acesso ao serviço de API usando um perímetro do VPC Service Controls.

O público-alvo deste documento inclui arquitetos, desenvolvedores e administradores que criam e gerenciam infraestrutura e apps de IA do Google Cloud. Este documento pressupõe que você tenha um entendimento básico de agentes e modelos de IA e que conheça os conceitos de rede do Google Cloud .

Padrão de design multiagente

Um app multiagente do Gemini Enterprise requer um agente personalizado para servir como orquestrador ou agente raiz para conexões com ferramentas e subagentes. Para implementar conexões particulares com ferramentas e subagentes hospedados no Google Cloud ou no local, o design usa uma rede VPC com endereços IP particulares. O agente raiz é hospedado na infraestrutura do Google, usando o Agent Runtime, o Cloud Run ou o GKE. O padrão de design multiagente destaca estas interações:

  1. App do Gemini Enterprise interagindo com agentes raiz personalizados. Os apps do Gemini Enterprise apresentam uma interface do usuário gerenciada com funções de segurança integradas que expõem a funcionalidade do agente personalizado. Os agentes raiz personalizados são registrados no Gemini Enterprise e disponibilizados em apps para os usuários finais. O agente raiz personalizado atua como um orquestrador de fluxo de trabalho de nível superior e delega tarefas especializadas a subagentes. Essa arquitetura usa agentes raiz personalizados hospedados no Agent Runtime, no Cloud Run ou no GKE.
  2. Agentes raiz interagindo com subagentes e ferramentas. O núcleo do fluxo de trabalho do sistema de IA e da lógica de negócios reside no agente raiz e em subagentes especializados. A flexibilidade no framework do agente, no ambiente de execução e na plataforma de hospedagem permite diferentes opções para conectar agentes raiz a subagentes e ferramentas pela rede VPC. Ao usar a rede VPC para essa parte da arquitetura, os agentes podem usar caminhos de rede privada definidos por você que expõem outros endpoints privados, controles de segurança corporativa e maior Network Reachability.

Visão geral de uma arquitetura de rede multiagente.

A arquitetura inclui os seguintes componentes:

  • App Gemini Enterprise: o front-end para os usuários acessarem uma interface de chat no app e interagirem com o sistema de IA multiagente. Os usuários podem acessar os apps do Gemini Enterprise pela Internet pública ou de forma particular por conexões híbridas.
  • Agentes personalizados: agentes raiz criados e registrados no Gemini Enterprise e hospedados no Agent Runtime, no Cloud Run ou no GKE. Esses agentes raiz funcionam como orquestradores que delegam tarefas a subagentes.
  • Rede VPC: um recurso que você controla para fornecer aos agentes conectividade de rede IP com endpoints particulares e maior acessibilidade de rede. A rede VPC oferece uma plataforma para implementar conectividade privada e controles de segurança de rede para solicitações de agentes a outros agentes e ferramentas.
  • Subagentes: agentes especializados que são acionados pelo fluxo de trabalho do agente raiz. Os subagentes se comunicam usando o protocolo A2A, que permite a interoperabilidade entre agentes, independentemente da linguagem de programação e do ambiente de execução.
  • Ferramentas: sistemas remotos que expõem serviços como APIs, fontes de dados e funções de fluxo de trabalho. Essas ferramentas buscam dados e realizam ações ou transações para os agentes. As ferramentas são externas aos agentes, que se conectam e interagem com elas usando a especificação do MCP.

Esse padrão de design de alto nível destaca os componentes de rede que estão em um sistema de IA agêntica. Ele pode oferecer suporte a muitos tipos diferentes de padrões de roteamento entre agentes. Para informações sobre outros padrões de design de sistemas de IA, consulte Escolher um padrão de design para seu sistema de IA agêntica.

VPC compartilhada

O padrão de design de vários agentes usa a VPC compartilhada para centralizar a autoridade e a responsabilidade de rede e segurança. Esse design oferece aos desenvolvedores ambientes que ajudam a atender às necessidades de segurança de uma organização. Recomendamos que você use a VPC compartilhada para centralizar e simplificar as configurações de rede e segurança.

Em uma arquitetura de VPC compartilhada, um projeto host contém os recursos de rede compartilhados, incluindo redes VPC, Cloud Routers, sub-redes, firewalls e Cloud DNS. Os administradores podem conceder aos projetos de serviço acesso para usar esses recursos. Os projetos de serviço contêm os recursos do ambiente de execução do agente, incluindo o Agent Runtime, o Cloud Run, o GKE, o Gemini Enterprise e os balanceadores de carga específicos do app.

A VPC compartilhada impõe um limite claro entre as personas de administrador de rede e segurança e as personas de desenvolvedor de apps de IA:

  • Os administradores de rede e segurança controlam a infraestrutura principal, como roteamento de VPC, sub-redes, peering de DNS e políticas de firewall.
  • Os desenvolvedores de apps de IA criam agentes em projetos de serviço anexados sem ter permissões para modificar a infraestrutura de rede subjacente.

Ao centralizar as implantações de rede e segurança em um projeto host, você cria um único ponto de gerenciamento para a comunicação entre agentes e entre agentes e serviços. Esse design simplifica a aplicação de políticas de segurança em muitos projetos de serviço diferentes, garantindo uma conectividade consistente.

É possível incorporar sua rede VPC compartilhada a uma Cross-Cloud Network usando spokes VPC do Network Connectivity Center (NCC) para adicionar a rede VPC compartilhada como uma rede VPC de carga de trabalho. Essa implementação fornece à VPC compartilhada acessibilidade total às rotas do hub do NCC e conectividade com pontos de acesso de serviço de outros spokes.

As solicitações iniciadas por agentes raiz personalizados usam uma rede VPC particular gerenciada pelo cliente para fornecer caminhos de rede seguros para subagentes, ferramentas e serviços. O roteamento de rede VPC controla a acessibilidade a endpoints particulares. As políticas do Cloud NGFW aplicadas à rede VPC controlam o acesso à rede.

Os agentes têm acesso seguro a caminhos de rede VPC particulares, incluindo conectividade com:

  • Outras redes VPC por peering de rede VPC, dispositivos com várias NICs ou NCC.
  • Endpoints do Private Service Connect para acessar serviços de produtor.
  • Serviços gerenciados que têm endereços IP particulares, como o Cloud SQL.
  • Front-ends do balanceador de carga interno e recursos do Compute Engine.
  • APIs do Google pelo Acesso Privado do Google ou pelo Private Service Connect.
  • A Internet, controlada pelo Secure Web Proxy.
  • Destinos híbridos e entre nuvens usando o Cloud Interconnect, o Cloud VPN, o dispositivo roteador ou a SD-WAN.
  • Qualquer destino de endpoint que possa ser acessado pelo roteamento de IP da rede VPC.
  • Outros agentes de IA, ferramentas e serviços de suporte.

Para mais informações sobre a VPC compartilhada, consulte estes recursos:

Rede do Gemini Enterprise

Os apps do Gemini Enterprise são recursos gerenciados que operam em um ambiente hospedado fora da rede VPC, mas dentro da rede do Google. As seções a seguir descrevem a configuração de rede entre o usuário e o app do Gemini Enterprise e descrevem a rede entre o app e os agentes.

Conversa do usuário com os apps do Gemini Enterprise

Os usuários conversam com o app do Gemini Enterprise usando um app baseado em navegador que envia solicitações para APIs e serviços do Google. Para ativar a conectividade de usuário particular, configure os URLs da API do Google para serem resolvidos em intervalos de endereços IP particulares roteados pela rede VPC. Para mais informações, consulte Configurar o acesso particular à interface.

Apps do Gemini Enterprise para agentes personalizados

Registre agentes personalizados com o serviço de descoberta do Gemini Enterprise. Quando você registra um agente, o Gemini Enterprise mapeia o nome dele para um destino específico, que pode ser o URI do recurso do Agent Runtime ou o URL do agente A2A. Os apps do Gemini Enterprise têm uma interface de chat integrada chamada assistente. Quando um usuário especifica um agente usando @agent_name ou quando o assistente decide delegar, o app procura o agente no registro para encontrar o endpoint associado.

Ao registrar um agente raiz no Gemini Enterprise, é possível implantá-lo em qualquer lugar como um agente personalizado. Os agentes personalizados no Agent Runtime e no Cloud Run podem usar caminhos de rede privada sem configurar recursos de rede adicionais. Para implantar um agente personalizado no GKE, é necessário expor o serviço com um gateway externo. Para saber como configurar o gateway externo para ser mais seguro, consulte Rede do GKE mais adiante neste documento.

Para fazer solicitações a agentes personalizados, o Gemini Enterprise usa a identidade da conta de serviço do Discovery Engine da Gemini Enterprise Agent Platform. O caminho de rede e os mecanismos de autorização variam de acordo com a plataforma de hospedagem que você usa:

  • Agentes personalizados no Agent Runtime: o agente de serviço do Discovery Engine da Agent Platform inclui os papéis necessários do Identity and Access Management (IAM) da Agent Platform para invocar recursos do Agent Runtime como um recurso integrado. O sistema encaminha as solicitações feitas ao serviço da API Agent Platform pela rede do Google como uma chamada de API interna.
  • Agentes personalizados no Cloud Run: os apps do Gemini Enterprise usam a identidade do agente de serviço do Discovery Engine da plataforma de agentes para fazer chamadas para o URL padrão .run.app registrado no card do agente, anexando o token de ID do OIDC do agente de serviço no X-Serverless-Authorization cabeçalho de autenticação. Para que o serviço do Cloud Run do agente de IA autorize essas chamadas, é necessário conceder o papel do IAM de invocador do Cloud Run (roles/run.invoker) ao agente de serviço do Discovery Engine. As solicitações para o Cloud Run são roteadas pela rede de produção do Google para a entrada do Google Front End (GFE) para o Cloud Run.

  • Agentes personalizados no GKE: os apps do Gemini Enterprise usam a identidade do agente de serviço do Discovery Engine da plataforma de agentes para fazer chamadas para o URL registrado no card do agente. O DNS público precisa ser capaz de resolver o nome do host para um endereço IP externo gerenciado pelo gateway. Recomendamos que você use o balanceador de carga gke-l7-regional-external-managed ou o balanceador de carga gke-l7-global-external-managed. Para maior segurança, recomendamos que o Gemini Enterprise chame um agente A2A hospedado no GKE usando o Identity-Aware Proxy (IAP). Para que o IAP autorize essas chamadas, é necessário conceder o papel do IAM de usuário do app da Web protegido pelo IAP (roles/iap.httpsResourceAccessor) ao agente de serviço do Discovery Engine. A rede de produção do Google encaminha solicitações para o GKE para o GFE para entrada do balanceador de carga de aplicativo externo.

    Para proteger a entrada do GKE do Gemini Enterprise, consulte as seções IAP e Google Cloud Armor mais adiante neste documento.

Rede privada para plataformas de hospedagem de agentes

Depois que um usuário inicia uma solicitação para o app do Gemini Enterprise, as solicitações são iniciadas de agentes raiz personalizados para subagentes e ferramentas. As plataformas de hospedagem de agentes personalizados fornecem a interface entre o Gemini Enterprise e suas redes VPC. As plataformas de hospedagem para seus agentes e ferramentas conteinerizados são o Agent Runtime, o Cloud Run e o GKE.

Ao escolher uma plataforma de hospedagem de agentes, é preciso considerar os padrões de rede privada, os controles de segurança, o controle de gerenciamento, o nível de personalização e a conformidade de segurança de cada plataforma. Para mais informações sobre como selecionar uma plataforma de hospedagem de agentes de IA, consulte Escolher modelos e infraestrutura para seu aplicativo de IA generativa e Escolher os componentes da arquitetura de IA agêntica.

Você estabelece a conectividade de VPC privada por meio de diferentes mecanismos com base na plataforma de hospedagem de agentes que você usa:

  • Agentes personalizados no Agent Runtime: as interfaces do Private Service Connect conectam os ambientes de execução do Agent Runtime à rede VPC. Crie um anexo de rede em uma sub-rede da sua rede VPC e conceda ao Agent Runtime permissão de execução para se conectar a ele. O tráfego enviado do Agent Runtime aparece na rede VPC como se tivesse sido originado no endereço IP da sub-rede do anexo. Em seguida, a rede VPC roteia o tráfego para o endereço IP de destino apropriado.
  • Agentes personalizados no Cloud Run: a saída de VPC direta do Cloud Run conecta as instâncias de serviço do Cloud Run à rede VPC. A rede VPC especificada quando um serviço do Cloud Run é implantado pode ser do projeto de serviço do Cloud Run ou do projeto host da VPC compartilhada. O tráfego enviado do Cloud Run aparece na rede VPC como se tivesse origem no endereço IP da sub-rede da saída de VPC direta. A rede VPC encaminha o tráfego para o endereço IP de destino apropriado.
  • Agentes personalizados no GKE: os clusters do GKE residem diretamente na rede VPC e usam endereços IP de sub-rede local. Por padrão, o tráfego de saída do GKE usa o endereço IP do pod como o endereço IP de origem. Se você configurar o mascaramento, o tráfego de saída do GKE vai usar o endereço IP do nó como o endereço IP de origem. Todo o tráfego de saída do GKE é roteado pela rede VPC.

As seções a seguir fornecem mais orientações para gerenciar solicitações de entrada e saída da rede VPC para cada plataforma de hospedagem de agentes. As considerações de rede são aplicáveis à funcionalidade do agente raiz e do subagente.

Rede do Agent Runtime

Nesta seção, descrevemos a rede privada para agentes raiz e subagentes hospedados no Agent Runtime. Se você estiver usando o Agent Runtime para hospedar seu agente raiz, implante o Gemini Enterprise e o Agent Runtime no mesmo projeto.

O Agent Runtime hospeda contêineres na infraestrutura do Google fora da sua rede VPC. Para ativar a conectividade privada com outros agentes, conecte seu agente à rede VPC usando os seguintes métodos:

Para permitir solicitações entre seus agentes e outros, configure as duas conexões anteriores.

Saída do Agent Runtime para a rede VPC

O Agent Runtime usa um projeto de locatário gerenciado pelo Google para saída de rede. A rede de locatário fornece conectividade para que os agentes acessem as APIs do Google e para a saída de dados para a Internet pública, mas não está diretamente conectada às redes VPC do cliente por padrão.

Para conectar agentes a recursos que estão dentro da sua rede VPC, o Agent Runtime usa interfaces do Private Service Connect. O Agent Runtime implanta uma interface de rede no projeto de locatário que se conecta a um recurso de anexo de rede no seu projeto. Essa conexão cria um caminho de dados seguro entre o ambiente de execução do Agent Runtime e a rede VPC. Quando você configura uma interface do Private Service Connect no projeto do Agent Runtime, o sistema encaminha todo o tráfego do agente que não é destinado às APIs do Google para a rede VPC.

Para implantar a saída de rede VPC do Agent Runtime, consulte estes recursos:

Para proteger ainda mais os agentes e a rede VPC para a saída do Agent Runtime, consulte estas seções mais adiante neste documento:

Entrada do Agent Runtime pela rede VPC

As solicitações para agentes que são executados no Agent Runtime são feitas usando o endpoint de API Agent Platform (aiplatform.googleapis.com). Para acessar os endpoints da API do Google usando caminhos de rede privada da rede VPC, use o Acesso Privado do Google ou os endpoints do Private Service Connect para APIs do Google.

Os usuários particulares que fazem consultas a agentes precisam resolver o nome do host do endpoint de API do Agent Platform para o intervalo de endereços IP particulares do Acesso Privado do Google ou para o endereço IP do endpoint do Private Service Connect para APIs do Google. Uma zona de Cloud DNS gerenciada e particular para googleapis.com resolve solicitações para a API Agent Platform. A rede VPC roteia a solicitação diretamente pela rede de produção do Google.

Se você usa o Acesso Privado do Google ou o Private Service Connect para APIs do Google, é possível proteger o tráfego da sua rede VPC para o Agent Runtime usando os seguintes produtos e recursos:

Outras considerações sobre a rede do Agent Runtime

A saída do Agent Runtime que usa interfaces do Private Service Connect só pode ser roteada para intervalos de endereços IP RFC 1918 na rede VPC. Para intervalos de destino específicos que não são roteáveis pela saída do Agent Runtime, consulte Requisitos de intervalo de IP da sub-rede. Para alcançar destinos de intervalo de endereços IP não roteáveis, use uma configuração de proxy explícita nos agentes e implante recursos de proxy que usem um endereço IP roteável na rede VPC.

Quando o Agent Runtime é implantado sem uma interface do Private Service Connect, ele tem acesso à Internet por padrão. Para se proteger contra a exfiltração de dados, desative o acesso padrão ativando o VPC Service Controls.

Quando o Agent Runtime é implantado com uma interface do Private Service Connect, a saída de dados para a internet é desativada, independentemente do VPC Service Controls. Se você precisar que o agente acesse um destino que o Agent Runtime normalmente não consegue alcançar, como a Internet, faça o seguinte:

  1. Configure o Secure Web Proxy em uma sub-rede RFC 1918 da sua rede VPC. Configure o proxy no modo de roteamento de proxy explícito.
  2. Crie um registro DNS do Cloud DNS para o nome do host do Secure Web Proxy.
  3. Configure o peering de DNS para que o Agent Runtime ofereça suporte à resolução de consultas DNS do agente para o endereço privado do Secure Web Proxy na rede VPC.
  4. Ao implantar agentes, faça o seguinte:
    1. Defina variáveis de ambiente para usar o proxy explícito especificando o nome do host e a porta do Secure Web Proxy.
    2. Se você estiver acessando um destino particular, configure uma zona de DNS particular para ele.

Depois que o tráfego da saída do Agent Runtime chega à rede VPC, ele pode alcançar qualquer destino de rede roteável pela rede VPC. Para saber como limitar o escopo dos destinos de rede de saída disponíveis para os agentes do Agent Runtime, consulte a seção Cloud NGFW mais adiante neste documento.

Rede do Cloud Run

Nesta seção, descrevemos a rede privada para agentes raiz e subagentes hospedados no Cloud Run. O Cloud Run hospeda contêineres na infraestrutura do Google fora da sua rede VPC. Para ativar a conectividade particular com outros agentes, conecte seu agente à rede VPC usando os seguintes métodos:

Para permitir solicitações entre seus agentes e outros, configure as duas conexões anteriores.

Saída do Cloud Run para a rede VPC

Para iniciar conexões do Cloud Run em uma rede VPC, recomendamos usar a saída de VPC direta. Com a saída de VPC direta, as instâncias do Cloud Run se conectam diretamente à rede VPC compartilhada usando um endereço IP da sub-rede que você especifica ao implantar a saída de VPC direta.

Ao configurar a saída de VPC direta, faça o seguinte:

  1. Configure a sub-rede de destino com o Acesso privado do Google ativado.
  2. Configure o roteamento de tráfego para encaminhar todo o tráfego para a rede VPC.

Essa configuração envia todo o tráfego pela rede VPC para garantir a privacidade e envia solicitações do Cloud Run para outras APIs do Google pela rede interna do Google.

Todas as consultas DNS do Cloud Run usam a política e as zonas do Cloud DNS associadas à rede VPC. Nenhuma outra configuração de peering de DNS é necessária. Os agentes hospedados no Cloud Run resolvem todas as zonas particulares do Cloud DNS e os nomes de host públicos.

Para saber como proteger ainda mais os agentes e a rede VPC para a saída do Cloud Run, consulte estas seções mais adiante neste documento:

Entrada do Cloud Run pela rede VPC

O Cloud Run é uma plataforma gerenciada pelo Google que opera em um ambiente fora da rede VPC. Esse ambiente hospeda o endpoint de URL estável *.run.app para serviços do Cloud Run que executam cargas de trabalho de agentes ou ferramentas de IA. Esses endpoints são disponibilizados pelo mesmo ponto de entrada do GFE que disponibiliza os serviços de API do *.googleapis.com. O Cloud Run usa os mesmos caminhos de rede subjacentes que permitem a conectividade particular para o Acesso privado do Google e para o Private Service Connect para APIs do Google.

Os usuários particulares na rede VPC que fazem consultas a agentes ou ferramentas precisam resolver o nome do host run.app para o intervalo de endereços IP particulares do Acesso privado do Google ou para o endereço IP do endpoint do Private Service Connect para APIs do Google. Uma zona particular gerenciada do Cloud DNS para o URL run.app resolve solicitações de serviços do Cloud Run. A rede VPC roteia a solicitação diretamente pela rede de produção do Google.

Definir a entrada do Cloud Run como Interna restringe o acesso ao serviço, permitindo solicitações apenas de fontes internas verificadas. As fontes aprovadas incluem:

  • Redes VPC do projeto de serviço do Cloud Run.
  • A rede VPC compartilhada que hospeda o endpoint de saída de VPC direta.
  • Recursos que estão no mesmo perímetro do VPC Service Controls.
  • Balanceadores de carga de aplicativo internos na rede VPC.
  • Serviços do Google, como o Cloud Scheduler e o Pub/Sub, que estão no projeto de serviço ou no perímetro do VPC Service Controls.

Se você não usar um perímetro comum do VPC Service Controls para abranger os serviços de chamada e de chamada, o tráfego de fora do projeto de serviço do Cloud Run ou do ambiente de VPC compartilhada será tratado como externo. Isso inclui o tráfego de outros serviços do Google Cloud, como o Agent Runtime e outros serviços do Cloud Run. Para atender à verificação de entrada interna do Cloud Run, esse tráfego precisa ser roteado de modo que pareça se originar da rede VPC do serviço de destino.

Para fornecer a atribuição de rede interna necessária, faça o seguinte:

  • Use os endpoints do Private Service Connect para permitir que serviços em outras VPCs ou projetos se conectem a APIs e serviços do Google, incluindo o serviço do Cloud Run, usando um endereço IP particular na rede VPC.
  • Encaminhe o tráfego por um balanceador de carga de aplicativo interno colocado na rede VPC na frente do serviço do Cloud Run. O balanceador de carga canaliza as solicitações de outros serviços pela rede VPC para que atendam aos critérios de entrada interna.

Os balanceadores de carga de aplicativo internos com back-ends de grupo de endpoints de rede (NEG) sem servidor criam um recurso de VPC que é mapeado diretamente para um serviço do Cloud Run. Nesse modelo, o balanceador de carga encerra as conexões TLS do cliente com um certificado confiável. Os balanceadores de carga de aplicativo internos são compatíveis com outros controles de segurança, incluindo as políticas de segurança de back-end do Cloud Armor e outras políticas de autorização.

Por padrão, o acesso a todos os serviços do Cloud Run requer autenticação do IAM. Recomendamos que você use uma identidade por serviço e conceda ao principal o papel do IAM de invocador do Cloud Run (roles/run.invoker).

Para saber como configurar os controles de entrada do Cloud Run, consulte estes recursos:

Se você usa o Acesso privado do Google ou os endpoints do Private Service Connect para APIs do Google para enviar tráfego da sua rede VPC para o Cloud Run, é possível proteger esse tráfego usando os seguintes produtos e recursos:

Se você usar um balanceador de carga de aplicativo interno para enviar tráfego da sua rede VPC para o Cloud Run, poderá proteger esse tráfego usando os seguintes produtos e recursos:

Rede do GKE

Nesta seção, descrevemos a rede para agentes baseados no GKE.

GKE e Gemini Enterprise

Como host para agentes e ferramentas de IA, o GKE oferece uma plataforma altamente personalizável para controles de rede e segurança. Um sistema de IA multiagente implantado no GKE pode fornecer eficiência operacional em larga escala. Ele pode ser integrado a outros apps do Kubernetes e a arquiteturas de microsserviços maiores.

Os clusters do GKE são nós de VM do Compute Engine que são executados em uma sub-rede da rede VPC. Os apps do Gemini Enterprise são recursos gerenciados que operam em um ambiente hospedado fora da rede VPC. Para permitir que os apps do Gemini Enterprise chamem agentes personalizados hospedados no GKE, é necessário expor com segurança um gateway externo com um endereço IP público e um nome de DNS. O tráfego flui da saída do Gemini Enterprise para a rede de borda do Google, onde segue uma rota otimizada para o balanceador de carga externo do GKE.

É importante proteger o endpoint do GKE usando autenticação e autorização fortes, o Cloud Armor e permissões limitadas. Para fornecer um modelo abrangente de defesa em profundidade para proteger os agentes de IA que são executados no GKE, considere os controles de segurança descritos nas seções a seguir.

Modo de operação do GKE

O GKE oferece estes modos de operação para equilibrar o gerenciamento e o controle:

  • Autopilot: o Google automatiza toda a infraestrutura do cluster do GKE, incluindo o plano de controle, o provisionamento de nós, o aumento da segurança e o escalonamento.
  • Padrão: o Google gerencia o plano de controle. Você mantém total responsabilidade pelas configurações do pool de nós, como selecionar tipos de máquina, gerenciar imagens do SO e escalonamento manual.
Reforço da proteção da infraestrutura e do plano de controle
  • Clusters particulares do GKE: provisione nós sem endereços IP públicos, o que garante que o ambiente de execução seja isolado da exposição direta à Internet.
  • Redes autorizadas do mestre: restrinja o acesso administrativo à API do Kubernetes a intervalos de endereços IP específicos e confiáveis, o que protege o plano de controle contra alterações de configuração não autorizadas. Proteja o endpoint de DNS para a API Kubernetes usando o IAM e o VPC Service Controls do Google Cloud.
Identidade e acesso (zero trust)
  • IAP: atua como um intermediário no nível do balanceador de carga. Ele garante que apenas usuários autenticados com as permissões corretas do IAM possam acessar o endpoint do agente. Essa abordagem muda efetivamente o perímetro de segurança da rede para o usuário individual e o contexto do dispositivo.
Proteção de borda e gerenciamento de tráfego
  • Cloud Armor: oferece segurança de borda robusta, incluindo regras de firewall de aplicativos da Web (WAF) para ajudar a bloquear payloads maliciosos, proteção contra DDoS para ajudar a garantir o tempo de atividade e limitação de taxa para ajudar a evitar o esgotamento do serviço.
  • Model Armor: projetado especificamente para a segurança de LLMs, o Model Armor inspeciona e limpa comandos e respostas em tempo real para evitar a injeção de comandos e a exfiltração de dados.
Isolamento de rede interna
  • Políticas de rede do Kubernetes: aplica uma comunicação granular e de privilégio mínimo entre microsserviços. Por padrão, as políticas negam todo o tráfego, a menos que você o permita explicitamente, o que impede o movimento lateral no cluster.

Saída do GKE para a rede VPC

A rede VPC roteia conexões de saída de agentes hospedados no GKE. O modo de rede padrão do cluster do GKE é nativo de VPC, que fornece os seguintes atributos:

  • O cluster do GKE usa intervalos de endereços IP de alias.
  • Os endereços IP de pods são reservados especificando o intervalo de IP de pods.
  • Os endereços IP do pod são nativamente roteáveis na rede VPC do cluster e em outras redes VPC conectadas.

Se um pod de agente estiver se comunicando com um pod de subagente no mesmo nó, o tráfego será roteado localmente no namespace de rede do nó. Se o pod do agente de destino estiver em um nó diferente dentro do cluster, o tráfego será roteado usando a tabela de roteamento da rede VPC. Para que um pod de agente se comunique com outros recursos da VPC, como balanceadores de carga ou endpoints do Private Service Connect, ele pode chegar ao destino usando o mesmo roteamento padrão da VPC, sujeito às regras de firewall.

Para proteger o tráfego que sai do cluster do GKE, use os seguintes produtos e serviços:

Entrada do GKE pela rede VPC

Os serviços do Kubernetes dão acesso aos recursos do GKE. Para um sistema de IA multiagente, recomendamos usar um gateway do GKE ou um gateway de inferência do GKE. O gateway oferece recursos aprimorados com controle de tráfego, separação operacional de recursos e integrações de segurança. No entanto, outras opções de serviço de entrada estão disponíveis, dependendo dos requisitos do sistema.

O recurso Gateway cria um balanceador de carga de aplicativo e provisiona todos os componentes de balanceamento de carga necessários. Os grupos de endpoints de rede de back-end do serviço são conectados para fornecer balanceamento de carga diretamente aos contêineres. Para expor um serviço internamente para o tráfego proveniente da rede VPC, use as classes de gateway para o balanceador de carga de aplicativo interno regional (gke-l7-rilb) ou o balanceador de carga de aplicativo interno entre regiões (gke-l7-cross-regional-internal-managed-mc).

Os balanceadores de carga de aplicativo oferecem mais pontos de controle de segurança para proteger os agentes e as ferramentas de IA hospedados em clusters do GKE:

  • Cloud Armor: protege os serviços anexando uma política de segurança do Cloud Armor aos serviços de back-end gerenciados pelo gateway. Ele oferece triagem de WAF, filtragem de endereço IP e geográfica, proteção contra DDoS e limitação de taxa antes que o tráfego chegue ao cluster do GKE ou ao IAP.
  • IAP: ativado no serviço de back-end para controlar o acesso a apps usando credenciais do IAM, o IAP aplica políticas de acesso de confiança zero. O IAP autentica e autoriza os agentes de IA que acessam os recursos do cluster, incluindo apps do Gemini Enterprise, agentes personalizados e recursos externos. Ele exige que os autores de chamadas tenham uma identidade autenticada pelo IAM e permissão autorizada para acessar o serviço de back-end.

Se você enviar tráfego da sua rede VPC para o serviço do GKE por um gateway, poderá proteger esse tráfego usando os seguintes produtos e recursos:

Se você não usa um gateway para enviar tráfego da sua rede VPC para o serviço do GKE, é possível proteger esse tráfego usando os seguintes produtos e serviços:

Para mais informações sobre como proteger o GKE, consulte Práticas recomendadas de segurança de rede e Noções básicas sobre segurança de rede no GKE.

Segurança de rede do agente

Para proteger a rede de um sistema de IA agêntica multiagente, é necessário proteger as comunicações pela rede VPC e pela superfície da API. O plano de dados da rede VPC aborda como os agentes e as ferramentas se conectam de forma segura. A superfície da API define quais identidades e tipos de troca de dados são permitidos. A sobreposição de controles de acesso na rede VPC e na superfície da API ajuda a aplicar uma postura de segurança altamente controlada e resiliente.

Cloud NGFW

O Cloud NGFW atua como o gatekeeper no nível da rede para proteger as comunicações A2A e MCP. O firewall garante que apenas o tráfego autorizado possa chegar aos endpoints do agente, verificando todas as conexões de entrada ou saída de e para outros agentes e ferramentas.

O Cloud NGFW é um serviço de firewall distribuído integrado à estrutura de rede VPC. Ele oferece estes níveis de recursos que operam em diferentes camadas da pilha de rede:

  • Cloud Next Generation Firewall Essentials: oferece filtragem de pacotes de firewall com estado. As regras de política são definidas com base em endereços IP (L3), protocolos e portas (L4).
  • Cloud Next Generation Firewall Standard: oferece aplicação de políticas com base em IP com objetos de nome de domínio totalmente qualificado (FQDN, na sigla em inglês), objetos de geolocalização e feeds do Google Threat Intelligence para bloquear endereços mal-intencionados conhecidos.
  • Cloud Next Generation Firewall Enterprise: oferece recursos de inspeção de aplicativos (L7) com descriptografia de TLS e sistema de detecção e prevenção de intrusões (IDPS) para analisar payloads em relação a assinaturas de ameaças avançadas.

O Cloud NGFW pode ser aplicado à rede VPC para aplicar a política de firewall com base nas regras necessárias para segmentar a plataforma de hospedagem de agentes que você usou.

  • Agent Runtime: os agentes que são executados no Agent Runtime se conectam à rede VPC usando anexos de rede do Private Service Connect. Esses anexos fazem com que a interface de rede do agente apareça em uma sub-rede na rede VPC. As políticas de firewall de rede do Cloud NGFW são aplicadas à rede VPC. As políticas filtram o tráfego com base nos endereços IP de origem da sub-rede dedicada ao anexo de rede do Private Service Connect. Para correspondência de tráfego, use intervalos de endereços IP de origem e de destino.
  • Cloud Run: os serviços do Cloud Run que usam a saída VPC direta enviam tráfego diretamente de instâncias que são executadas em uma sub-rede especificada na rede VPC. As políticas de firewall de rede do Cloud NGFW se aplicam à sub-rede usada pelo Cloud Run para filtrar o tráfego. Para correspondência de tráfego, é possível usar intervalos de endereços IP de origem e de destino.
  • GKE: os clusters do GKE nativos de VPC fornecem aos pods endereços IP que são diretamente dos intervalos de endereços IP secundários da rede VPC. As políticas de firewall de rede podem filtrar o tráfego com base em intervalos de endereços IP para nós e pods do GKE, e as políticas podem usar tags seguras e contas de serviço. As tags seguras são vinculadas às instâncias de VM que atuam como nós do GKE. As regras de firewall podem segmentar ou originar o tráfego de nós que têm tags específicas. As regras de firewall também podem segmentar ou originar o tráfego de nós do GKE com base na identidade da conta de serviço associada ao pool de nós.

Política de saída de negação padrão

Implementar uma estratégia de negação padrão é uma prática recomendada de segurança que segue o princípio de privilégio mínimo. Essa estratégia garante que apenas o tráfego de rede explicitamente permitido seja autorizado, enquanto todo o outro tráfego é bloqueado por padrão. Essa implementação é alcançada pela estruturação de regras de firewall com regras ALLOW de alta prioridade para fluxos legítimos conhecidos e uma regra DENY de baixa prioridade que abrange tudo. Todos os níveis do Cloud NGFW permitem regras com base em intervalos de endereços IP de origem e destino.

As regras de política de firewall podem corresponder de forma eficaz ao tráfego de origem da sub-rede de anexo de rede do Agent Runtime e da sub-rede de saída de VPC direta do Cloud Run.

Veja a seguir um exemplo de política de saída de negação padrão:

  • Criar política e regras de firewall de rede: crie uma política de firewall global ou regional e associe-a à rede VPC. Crie regras de política de firewall que segmentem o tráfego na direção de saída (--direction=EGRESS) com base nos intervalos de endereços IP de origem (--src-ip-ranges=SRC_IP_RANGES) e de destino (--dest-ip-ranges=DEST_IP_RANGES).
  • Regras específicas de ALLOW: use números de prioridade mais baixos, por exemplo, 100-1000. Essas regras permitem precisamente o tráfego de rede necessário para que os agentes de IA funcionem. Esse tráfego inclui a comunicação com outros serviços internos, balanceadores de carga, APIs do Google necessárias ou endpoints externos legítimos. Crie uma regra que corresponda ao tráfego de origem da sub-rede do anexo de rede do Agent Runtime ou da sub-rede de saída de VPC direta do Cloud Run para os destinos que você quer.
  • Regra geral DENY: para garantir que a regra seja a última na ordem de avaliação, use o número de prioridade mais alto, por exemplo, 2147483647. Essa regra nega o tráfego para qualquer destino (--dest-ip-ranges=0.0.0.0/0) que não corresponda a nenhuma das regras ALLOW anteriores.

Uma política de negação de saída padrão impede que os agentes de IA façam conexões de rede que não sejam explicitamente autorizadas e bloqueia possíveis exfiltrações de dados ou acesso a sites maliciosos. A política limita os agentes hospedados a se comunicarem apenas com endpoints aprovados, o que é crucial para manter o controle sobre cargas de trabalho autônomas.

Outras considerações sobre a política do Cloud NGFW

Além da estratégia de negação padrão disponível em todos os níveis do Cloud NGFW, é possível reforçar ainda mais a segurança de rede da IA agêntica multiagente usando recursos de nível pago:

  • Recursos padrão do Cloud NGFW Standard:
    • Objetos FQDN para endpoints dinâmicos: os agentes de IA geralmente interagem com APIs externas, endpoints de modelo ou fontes de dados com endereços IP que podem mudar. Para acesso consistente aos serviços necessários por nome de domínio, use objetos FQDN em regras ALLOW.
    • Controles de geolocalização: se os agentes de IA tiverem requisitos de conformidade ou não puderem interagir com serviços em regiões geográficas específicas, use objetos de geolocalização (--src-region-codes=SRC_COUNTRY_CODES) nas regras de firewall para restringir o tráfego de ou para esses locais.
    • Google Threat Intelligence: use o Google Threat Intelligence em filtros de saída para impedir automaticamente que os agentes se conectem a destinos maliciosos conhecidos, como servidores de comando e controle (C2), anonimizadores como o Tor e sites de distribuição de malware. O uso do Google Threat Intelligence ajuda a conter o impacto de um agente potencialmente comprometido. Recomendamos que você inclua esses filtros de destino nas regras DENY de número de prioridade mais alto (ordem de avaliação mais baixa).
  • Recursos do Cloud NGFW Enterprise:
    • Inspeção da camada 7: para agentes que processam dados sensíveis ou que estão expostos a riscos maiores, inspecione os payloads de pacotes em busca de ameaças como malware, spyware e exploits que não são analisados pelas regras de firewall da camada de rede.
    • Inspeção de TLS: para permitir que o mecanismo de inspeção analise o tráfego criptografado, ative a inspeção de TLS. O uso da inspeção de TLS é crucial, porque a maioria dos ataques modernos e da comunicação C2 é criptografada.

Para outras considerações ou limitações de implementação que podem ser aplicáveis ao seu ambiente, consulte estes recursos:

IAP

O IAP protege as solicitações de entrada para clusters do GKE fornecendo uma camada central de autenticação e autorização para apps de IA. O IAP intercepta todas as solicitações HTTPS destinadas ao gateway e verifica a identidade e as permissões do autor da chamada. O IAP permite que apenas solicitações autenticadas e autorizadas sejam transmitidas para a carga de trabalho do serviço de back-end. O IAP no balanceador de carga do gateway protege apenas o tráfego que vem de fora do cluster. A comunicação dentro do cluster não passa pelo IAP.

Para acessar apps de IA hospedados no GKE e protegidos pelo IAP, as identidades de usuário principal precisam receber o papel do IAM de usuário do web app protegido pelo IAP (roles/iap.httpsResourceAccessor) no recurso de serviço de back-end protegido pelo IAP. Recomendamos que você configure uma conta de serviço personalizada como a identidade dos agentes implantados. Com uma conta de serviço personalizada, é possível atribuir permissões com mais precisão, de acordo com o princípio de privilégio mínimo.

Conceda o papel do IAM de usuário de app da web protegido pelo IAP diretamente às contas de serviço de agentes que têm permissão para acessar outros agentes e ferramentas hospedados no serviço do GKE que é o destino do recurso personalizado GCPBackendPolicy (ou BackendConfig para Entrada). Para permitir o acesso aos apps do Gemini Enterprise, conceda permissões vinculando o papel do IAM Conta de serviço do Discovery Engine (roles/discoveryengine.serviceAgent) ao seu projeto do Gemini Enterprise.

VPC Service Controls

O VPC Service Controls reduz os riscos de exfiltração de dados ao controlar rigorosamente o acesso às APIs do Google. Recomendamos que você implante um único perímetro macro que inclua todos os serviços compatíveis. Essa abordagem oferece a defesa mais robusta contra exfiltração. Para garantir a aplicação consistente de políticas em arquiteturas de VPC compartilhada, é fundamental incluir o projeto host e todos os projetos de serviço associados no mesmo perímetro de serviço.

Para proteger a interação entre o Gemini Enterprise e o Cloud Run em diferentes projetos, considere as seguintes recomendações:

  • Implantar um único perímetro do VPC Service Controls que englobe os projetos do Gemini Enterprise e do Cloud Run.
  • Adicione todos os serviços compatíveis do VPC Service Controls à lista de serviços restritos. Essa abordagem ajuda a evitar mudanças administrativas não autorizadas.
  • Aplique as configurações internas de entrada e autorização para bloquear todo o acesso à internet público aos serviços do Cloud Run.

Os serviços do Cloud Run são protegidos pelo IAM. Os autores da chamada precisam ser autenticados e ter o papel do IAM de invocador do Cloud Run (roles/run.invoker) no serviço de destino. O papel é verificado validando um token do cabeçalho Authorization (ou do cabeçalho X-Serverless-Authorization quando o Gemini Enterprise chama um URL .run.app padrão). Para chamar o serviço do Cloud Run, as contas de serviço, como as usadas pelo Gemini Enterprise, também precisam receber o papel de invocador do Cloud Run.

Quando o Gemini Enterprise e o Cloud Run são implantados em projetos diferentes, é necessário um perímetro do VPC Service Controls para definir a entrada do Cloud Run como Interna. Sem esse perímetro, as chamadas entre projetos do Gemini Enterprise são tratadas como tráfego externo, o que força você a definir a entrada do Cloud Run como "Todos", deixando o serviço exposto à Internet pública.

  • A entrada do Cloud Run all é compatível quando as duas condições a seguir são verdadeiras:
    • O VPC Service Controls não está ativado.
    • O Cloud Run e o Gemini Enterprise não estão no mesmo projeto.
  • Somente a entrada do Cloud Run internal é compatível com todas as outras configurações.

Outras considerações sobre o VPC Service Controls

Quando o Cloud Run é implantado em um perímetro do VPC Service Controls, recomendamos que você implemente as seguintes proteções de política para garantir uma proteção abrangente:

  • Restringir as configurações de entrada permitidas: evite que os desenvolvedores implantem acidentalmente endpoints públicos definindo a restrição da política da organização run.allowedIngress. Essa restrição se aplica apenas a novas implantações. As implantações anteriores podem não estar em conformidade. Recomendamos que você audite todos os serviços do Cloud Run no perímetro e reimplante ou atualize os que não atendem às configurações de entrada e saída necessárias.
    • Para permitir apenas solicitações internas, defina o valor como internal.
    • Para permitir solicitações por um balanceador de carga de aplicativo externo, defina o valor como internal-and-cloud-load-balancing.
  • Restringir as configurações de saída de VPC permitidas: para rotear todas as solicitações de saída pela VPC para que elas possam ser inspecionadas por regras de firewall de perímetro, defina o valor da restrição da política da organização run.allowedVPCEgress como all-traffic. Essa configuração exige que todas as revisões do Cloud Run usem a saída VPC direta ou um conector de acesso VPC sem servidor. Essa restrição só se aplica a novas implantações. As implantações anteriores podem não estar em conformidade. Recomendamos que você audite todos os serviços do Cloud Run no perímetro e reimplante ou atualize os que não atendem às configurações de entrada e saída necessárias.
  • Colocar imagens de contêiner e serviços no mesmo local: o repositório do Artifact Registry que contém as imagens de contêiner precisa estar no mesmo perímetro que o serviço do Cloud Run. A extração de imagens entre perímetros é bloqueada automaticamente, a menos que você estabeleça regras explícitas de entrada e saída.
  • Gerenciar níveis de acesso: as regras de política de entrada do VPC Service Controls e os níveis de acesso que dependem de identidades principais do IAM não são compatíveis com as invocações do Cloud Run. Em vez disso, gerencie o acesso com critérios baseados em rede ou níveis de acesso baseados em dispositivo.

Model Armor

O Model Armor é um serviço baseado em API que oferece mais segurança para apps de IA. Os agentes de IA interagem com o Model Armor fazendo chamadas para limpar os comandos do usuário antes que eles sejam enviados a um LLM e para limpar as respostas do modelo antes que elas sejam retornadas ao usuário. O Model Armor analisa ativamente os comandos e as respostas de LLMs, o que fornece um ponto de inspeção importante para detectar riscos emergentes e um ponto de controle para implementar padrões de IA responsável. Recomendamos que você use o Model Armor para garantir a conformidade com os requisitos de residência de dados e com as regulamentações legais de soberania de dados. Para usar o Model Armor em um perímetro do VPC Service Controls, é necessário configurar um endpoint do Private Service Connect para o endpoint regional do Model Armor na rede VPC.

O Model Armor é um serviço regional acessado de forma particular por meio de endpoints regionais do Private Service Connect na rede VPC. Por exemplo, o serviço us-central1 é chamado usando o endpoint regional modelarmor.us-central1.rep.googleapis.com. Os endpoints regionais ajudam a garantir a residência de dados.

Para permitir o acesso de agentes, configure os seguintes componentes em todas as regiões em que o serviço do Model Armor é necessário:

  1. Crie ou identifique uma sub-rede RFC 1918 na região da rede VPC em que o serviço do Model Armor está localizado.
  2. Crie um endpoint regional na sub-rede RFC 1918.
  3. Crie uma zona particular do Cloud DNS e um registro para o nome de host do endpoint regional do Model Armor (por exemplo, modelarmor.us-central1.rep.googleapis.com) que seja resolvido para o endereço IP do endpoint regional.
  4. Para a interoperabilidade do Agent Runtime, estabeleça o peering de DNS do Agent Runtime com a zona particular do Cloud DNS associada à sua rede VPC. Quando os agentes fazem solicitações ao Model Armor, o Cloud DNS resolve as solicitações de nome de host para o endereço IP do endpoint regional do Private Service Connect na rede VPC. Essa etapa não é necessária para agentes hospedados no Cloud Run e no GKE.

Para integrar o Gemini Enterprise ao Model Armor, crie um modelo do Model Armor no mesmo projeto do Gemini Enterprise. O local do modelo e do app do Gemini Enterprise precisa ser o mesmo.

Para mais informações sobre como ativar o Model Armor, consulte estes recursos:

Cloud Armor

O Cloud Armor é um serviço de segurança de rede distribuído que protege apps e serviços por trás de balanceadores de carga antes que as solicitações cheguem aos ambientes de execução do serviço de back-end. As cargas de trabalho de agentes de IA envolvem altos volumes de comunicação entre serviços que usam chamadas de API, MCP e A2A. A proteção do Cloud Armor oferece camadas extras de resiliência no design de segurança com limitação de taxa, triagem de WAF e regras personalizadas que estão em conformidade com as solicitações de agentes esperadas. Ao anexar políticas de segurança do Cloud Armor aos serviços de back-end do balanceador de carga de aplicativo, é possível filtrar o tráfego para solicitações maliciosas e policiá-lo com limites de taxa, além de mitigar ataques DDoS.

O Cloud Armor pode ser implantado em uma arquitetura de rede de agente nos seguintes cenários:

  • Cloud Run com balanceador de carga de aplicativo interno: proteja agentes e ferramentas que são executados no Cloud Run usando um balanceador de carga de aplicativo interno com back-ends de NEG sem servidor. Aplique políticas de segurança de back-end ao NEG sem servidor para aplicar regras de WAF ao tráfego interno e à limitação de taxa. Para controlar as comunicações do agente, defina outras regras personalizadas com base em endereços IP e cabeçalhos.
  • Gateway: proteja agentes e ferramentas que são executados no GKE usando uma definição de recurso de gateway para um balanceador de carga de aplicativo externo global ou regional com back-ends de NEG zonal. Use a API Gateway do Kubernetes para aplicar o recurso GCPBackendPolicy com a política de segurança definida do Cloud Armor. Se você usar um balanceador de carga de aplicativo externo regional, o Cloud Armor vai oferecer suporte a políticas de segurança de back-end com regras de WAF, endereço IP e controles baseados em região geográfica, além de limitação de taxa. Os balanceadores de carga de aplicativo externos globais são compatíveis com políticas de segurança de back-end e políticas de segurança de borda adicionais com a Proteção adaptativa do Google Cloud Armor e o Google Threat Intelligence.

Secure Web Proxy

O Secure Web Proxy é um serviço gerenciado regional implantado na rede VPC para filtrar o tráfego HTTP/S originado na rede VPC ou em qualquer rede conectada. Ele atua como um proxy centralizado e um ponto de aplicação de segurança para fornecer controle granular e visibilidade do tráfego de saída da Internet. Ele também atua como um proxy explícito para comunicações de serviço internas.

O Secure Web Proxy é compatível com três modos de implantação: modo de roteamento de proxy explícito, modo de anexo de serviço do Private Service Connect e modo de próximo salto. Recomendamos que você use o Secure Web Proxy no modo de roteamento de proxy explícito, que é o foco deste documento. Nesse modo, os clientes HTTP precisam ser configurados explicitamente para apontar diretamente para o endereço IP ou nome do host do Secure Web Proxy.

Para implantar o Secure Web Proxy na sua rede VPC, configure uma sub-rede de front-end e uma sub-rede somente proxy. O Secure Web Proxy é um serviço totalmente gerenciado. Quando o Secure Web Proxy é implantado, ele implanta e configura automaticamente o Cloud Router e o Cloud NAT na sua rede VPC para integração específica com o recurso de proxy. Essa configuração exige que todas as solicitações de saída passem pelo Secure Web Proxy antes de saírem para a Internet.

O uso do Secure Web Proxy como um proxy explícito é compatível com solicitações de agentes que vêm de interfaces do Private Service Connect do Agent Runtime, saída de VPC direta do Cloud Run e clusters do GKE nativos de VPC. Quando os agentes enviam solicitações ao Secure Web Proxy usando o método HTTP CONNECT, o tráfego da sessão TCP é encaminhado por túnel para o proxy em que as regras da política de segurança são aplicadas. Se o tráfego for permitido, o Secure Web Proxy o enviará para a saída de dados para a internet controlada ou para destinos de rede privada que podem ser roteados pela rede VPC.

Roteamento de proxy explícito

A saída do Agent Runtime exige que você use uma configuração de proxy explícita para que os agentes alcancem destinos da Internet ou intervalos de endereços IP não roteáveis na rede VPC. Para interoperabilidade do Agent Runtime, recomendamos que você configure o recurso Secure Web Proxy com um endereço IP RFC 1918 de uma sub-rede de front-end na rede VPC. Com essa configuração, o Secure Web Proxy se torna diretamente acessível pelo Agent Runtime. Em seguida, ele pode fazer proxy de todas as conexões com destinos de endereços IP não roteáveis que estão na rede VPC ou em redes conectadas.

Para que a plataforma de hospedagem de agentes use o Secure Web Proxy no modo de roteamento explícito, configure estes recursos de rede:

  1. Crie ou identifique uma sub-rede RFC 1918 na rede VPC para hospedar o recurso Secure Web Proxy.
  2. Crie um registro DNS do Cloud DNS para o nome do host do Secure Web Proxy (por exemplo, swp.example.com) que seja resolvido para o endereço IP do recurso do Secure Web Proxy.
  3. Para a interoperabilidade do Agent Runtime, estabeleça o peering de DNS do Agent Runtime com a zona particular do Cloud DNS associada à sua rede VPC. Quando os agentes fazem solicitações ao Secure Web Proxy, o Cloud DNS resolve as solicitações de nome de host para o endereço IP do recurso do Secure Web Proxy na rede VPC. Essa etapa não é necessária para agentes hospedados no Cloud Run e no GKE.

Configurações de proxy do agente

A maneira padrão de configurar apps de agente para usar um proxy HTTP(S) é definindo estas variáveis de ambiente:

  • HTTP_PROXY: o URL do servidor proxy explícito para tráfego HTTP (por exemplo, http://swp.example.com:8888). Essa configuração usa o método HTTP CONNECT do cliente para o proxy. Mesmo que o HTTP seja especificado, a criptografia TLS é mantida de ponta a ponta pelo proxy, do Agent Runtime do agente ao endpoint de destino.
  • HTTPS_PROXY: o URL do servidor proxy explícito para tráfego HTTPS (por exemplo, https://swp.example.com:8888). Assim como a configuração HTTP_PROXY, a configuração HTTPS_PROXY usa TLS por padrão. No entanto, é possível fornecer uma camada extra de criptografia ativando sua própria criptografia TLS sobre o TLS padrão. Para mais informações, consulte Certificate Authority Service.
  • NO_PROXY: uma lista separada por vírgulas de nomes de host ou endereços IP que não devem passar pelo proxy. Por exemplo, se você adicionar metadata.google.internal e 169.254.169.254 à lista NO_PROXY, as cargas de trabalho poderão acessar diretamente o serviço de metadados para autenticação e autorização de APIs e serviços do Google.

Quando você usa o argumento env_vars para definir variáveis durante a implantação, elas ficam disponíveis no ambiente de execução do agente (por exemplo, quando você usa os.environ em Python). A maioria das bibliotecas de cliente HTTP padrão descobre e usa automaticamente essas variáveis de ambiente para rotear o tráfego pelo proxy especificado. Essa abordagem é comum para apps Python e bibliotecas de cliente HTTP, como requests. Ao implantar agentes, defina variáveis de ambiente para usar o Secure Web Proxy em todos os domínios particulares que os agentes precisam acessar. Verifique se todos os destinos de domínio privado também estão incluídos no Cloud DNS.

O exemplo a seguir mostra uma implantação de proxy do Agent Runtime de um objeto de agente:

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
    },
)

O Cloud Run permite definir variáveis de ambiente no nível da revisão do serviço. Essa abordagem substitui todas as variáveis de ambiente com o mesmo nome que foram definidas na imagem do contêiner. Essa abordagem é útil para definir parâmetros operacionais, como variáveis de proxy, quando as instâncias de serviço são iniciadas.

O exemplo a seguir mostra o comando para definir as variáveis de ambiente ao implantar um serviço do 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"

Para implementar uma configuração de proxy explícito em pods do GKE, defina um recurso ConfigMap que especifique as variáveis de proxy:

apiVersion: v1
kind: ConfigMap
metadata:
  name: agent-proxy-config
  namespace: ai-apps
data:
  HTTP_PROXY: "http://swp.example.com:8888"
  HTTPS_PROXY: "http://swp.example.com:8888"

  NO_PROXY: "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

Para aplicar as chaves ConfigMap aos pods, use o campo envFrom no manifesto do contêiner. Essa especificação injeta as variáveis de ambiente no contêiner no ambiente de execução.

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

Serviço de CA

O CA Service é necessário quando o Secure Web Proxy ou o Cloud NGFW está configurado para inspeção de TLS. Quando a inspeção de TLS está ativada e o destino de uma carga de trabalho usa TLS, o CA Service cria e assina um certificado para esse destino. Quando o tráfego criptografado para o destino real chega ao Secure Web Proxy ou ao Cloud NGFW, ele descriptografa o pacote, o inspeciona e aplica as políticas. Se as políticas permitirem o pacote, o serviço vai criptografar novamente o pacote para o destino final. Também é possível usar o CA Service para fornecer certificados a outros serviços gerenciados pelo Google.

O Serviço de AC é um serviço gerenciado. Depois que o CA Service é configurado, ele lida com a assinatura de certificados de folha até que o certificado de CA raiz expire. Os certificados de CA raiz precisam ser atualizados para garantir que não expirem.

O CA Service oferece suporte a esses recursos para permitir a inspeção de tráfego e o gerenciamento de certificados em grande reduzir escalonamento horizontal uma arquitetura de IA multiagente:

  • Inspeção de TLS: o uso de uma CA particular é obrigatório para a inspeção de TLS completa. Para descriptografar e analisar totalmente os payloads HTTPS, o dispositivo de proxy intermediário (Secure Web Proxy ou Cloud NGFW) precisa encerrar a sessão TLS com o cliente. O proxy precisa apresentar um certificado válido que o cliente aceite como confiável para o domínio solicitado.

    O CA Service pode gerar e assinar dinamicamente um certificado de representação específico para o site solicitado. Quando o cliente tem o certificado de CA raiz particular instalado no repositório de confiança, ele aceita esse certificado criado dinamicamente como válido. O cliente confia no certificado enviado pelo proxy e, por isso, envia a solicitação. O proxy encerra a sessão TLS, descriptografa o pacote, inspeciona o conteúdo e, em seguida, aplica as políticas.

  • Distribuição de certificados: recursos de clientes internos, como agentes de IA que são executados no Agent Runtime, no Cloud Run ou no GKE, precisam do certificado de CA raiz particular adicionado aos repositórios de confiança locais. Ao armazenar a chave pública do certificado de CA raiz no Secret Manager, os agentes de IA podem extrair o certificado na inicialização e adicioná-lo ao repositório de confiança do sistema.

    Os recursos de servidor interno, como balanceadores de carga de aplicativo internos, precisam de certificados emitidos pela CA particular para atuar como endpoints de servidor confiáveis e encerrar sessões TLS de cliente. Os balanceadores de carga de aplicativo se integram às configurações de emissão do Gerenciador de Certificados para automatizar o CA Service que assina a solicitação de certificado e a implanta no balanceador de carga.

Para mais informações sobre operações de certificado, consulte estes recursos:

Segurança da conexão A2A

Os agentes raiz se comunicam com uma variedade de subagentes e servidores MCP que são implantados em várias plataformas de hospedagem de ambiente de execução. Cada ambiente introduz requisitos exclusivos de rede e segurança que precisam ser abstraídos pela camada A2A ou MCP.

O diagrama a seguir mostra os componentes e os possíveis caminhos de conexão compatíveis com este guia de design:

Padrões de conectividade Agent2Agent (A2A) entre diferentes plataformas de hospedagem, incluindo GKE, Cloud Run e Agent Runtime, além de conexões com servidores MCP e a Internet.

O diagrama anterior resume essas possibilidades de conexão:

  • Os usuários interagem com o sistema agentivo por um app do Gemini Enterprise.
  • O app do Gemini Enterprise usa a infraestrutura do Google para se conectar a um agente raiz que é executado no GKE, no Cloud Run ou no Agent Runtime.
  • O app Gemini Enterprise e os agentes raiz usam a infraestrutura do Google para se conectar ao Model Armor e ao LLM do Gemini na Agent Platform.
  • Os agentes raiz podem usar a infraestrutura do Google para se conectar a subagentes que são executados no Cloud Run ou no Agent Runtime.
  • Os agentes raiz podem usar endereços IP privados para se conectar a subagentes que são executados no Agent Runtime, no Cloud Run e no GKE. Essas conexões precisam ser roteadas por uma rede VPC.
  • Tanto os agentes raiz quanto os subagentes podem se conectar a servidores MCP que são executados no Cloud Run ou no GKE. Os agentes que se conectam aos servidores MCP podem usar a infraestrutura do Google ou uma rede VPC. Os servidores MCP dão acesso a ferramentas hospedadas no Google Cloud, no local, em outra nuvem ou na Internet.
  • Os serviços hospedados na Internet podem ser acessados diretamente pelo Secure Web Proxy.

As seções a seguir fornecem recursos para os caminhos de dados de ambiente de execução e os controles de segurança necessários para interações seguras de A2A. Essas informações servem como o padrão arquitetônico para estabelecer conectividade privada e implementar as defesas em várias camadas necessárias para proteger o caminho de dados de ponta a ponta entre os agentes.

Agente de origem do GKE

A tabela a seguir fornece recursos para ajudar você a proteger o tráfego quando o GKE é o agente de origem. Esse tráfego passa pela rede VPC que hospeda o cluster do GKE.

Agente de destino (caminho de dados) Controle de segurança
Agent Runtime (interno)
Cloud Run (interno)
Cloud Run (Private Service Connect para APIs do Google)
Acesso ao Cloud Run (NEG sem servidor)
GKE
Internet pela rede VPC

Agente de origem do Agent Runtime (interno)

A tabela a seguir fornece recursos para ajudar você a proteger o tráfego quando o Agent Runtime é o agente de origem e o tráfego passa diretamente pela infraestrutura do Google. Nesses caminhos, nenhuma rede VPC está envolvida.

Agente de destino (caminho de dados) Controle de segurança
Agent Runtime (interno)
Cloud Run (interno)

Agente de origem do Agent Runtime (interface do Private Service Connect)

A tabela a seguir fornece recursos para ajudar a proteger o tráfego quando o Agent Runtime é o agente de origem e o tráfego usa uma interface do Private Service Connect para passar por uma rede VPC.

Agente de destino (caminho de dados) Controle de segurança
Cloud Run (Private Service Connect para APIs do Google)
Acesso ao Cloud Run (NEG sem servidor)
GKE
Internet pela rede VPC

Agente de origem do Cloud Run (interno)

A tabela a seguir fornece recursos para ajudar você a proteger o tráfego quando o Cloud Run é o agente de origem e o tráfego passa diretamente pela infraestrutura do Google. Nesses caminhos, nenhuma rede VPC está envolvida.

Agente de destino (caminho de dados) Controle de segurança
Agent Runtime (interno)
Cloud Run (interno)

Agente de origem do Cloud Run (saída de VPC direta)

A tabela a seguir fornece recursos para ajudar a proteger o tráfego quando o Cloud Run é o agente de origem e o tráfego usa a saída de VPC direta para passar por uma rede VPC.

Agente de destino (caminho de dados) Controle de segurança
Cloud Run (Private Service Connect para APIs do Google)
Acesso ao Cloud Run (NEG sem servidor)
GKE
Internet pela rede VPC
Agent Runtime (Private Service Connect para APIs do Google)

Segurança da conexão MCP

A lista a seguir descreve as plataformas de hospedagem e os controles de defesa em profundidade envolvidos na proteção do caminho de dados entre os Agent Runtimes e os servidores MCP. Para agentes de origem no Agent Runtime, no Cloud Run ou no GKE, use os seguintes controles de segurança, dependendo do servidor MCP de destino:

  • Internet:
    • VPC Service Controls
    • Model Armor
    • Cloud NGFW
    • Secure Web Proxy
  • Google MCP:
    • VPC Service Controls
    • Model Armor

A seguir

Colaboradores

Autores:

  • Deepak Michael | Engenheiro de clientes especialista em rede
  • Michael Larson | Engenheiro de clientes, especialista em rede
  • Victor Moreno | Gerente de produtos, Cloud Networking

Outros colaboradores: