Padrões de rede particular multiagente no Google Cloud

Last reviewed 2026-04-16 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 acessível publicamente e com vários agentes, com conexões particulares entre agentes, subagentes e ferramentas. O design de rede oferece conexões particulares para agentes hospedados no Vertex AI Agent Engine, no Cloud Run, no Google Kubernetes Engine (GKE), em data centers locais ou em outras nuvens. O design também oferece suporte à conectividade com agentes que são executados em locais da Internet.

Os sistemas de IA multiagente geralmente envolvem dados sensíveis ou proprietários da organização. Com a rede particular, você evita expor esse tráfego à Internet pública. Esse design usa infraestrutura de rede Google Cloud , recursos de rede de nuvem privada virtual (VPC) e conectividade particular para ambientes locais ou redes entre nuvens.

No design descrito neste documento, os agentes se comunicam entre si e com ferramentas usando o protocolo Agent2Agent (A2A) e o Protocolo de Contexto de Modelo (MCP). As comunicações são feitas de forma privada ao serem 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 e interfaces do Private Service Connect e saída direta da VPC do Cloud Run. O Cloud Next Generation Firewall (Cloud NGFW) controla o tráfego que passa pela rede VPC. Outras camadas de segurança fornecem saída controlada da Internet usando o Secure Web Proxy e políticas de acesso a serviços 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 na nuvem. Neste documento, pressupomos que você tenha um conhecimento básico de agentes e modelos de IA e que esteja familiarizado com os conceitos de rede Google Cloud .

Padrão de design multiagente

Um app Gemini Enterprise multiagente exige 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 em 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 Engine, o Cloud Run ou o GKE. O padrão de design multiagente destaca estas interações:

  1. App 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 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 Vertex AI Agent Engine, no Cloud Run ou no GKE.
  2. Agentes raiz interagindo com subagentes e ferramentas. O núcleo do fluxo de trabalho e da lógica de negócios do sistema de IA reside no agente raiz e nos subagentes especializados. A flexibilidade na estrutura, no tempo de execução e na plataforma de hospedagem do agente permite diferentes opções para conectar agentes raiz a subagentes e ferramentas pela rede VPC. Ao usar redes VPC para essa parte da arquitetura, os agentes podem usar caminhos de rede particulares definidos por você que expõem outros endpoints particulares, controles de segurança empresarial e maior capacidade de alcance da rede.

Visão geral de alto nível 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 privada por conexões híbridas.
  • Agentes personalizados: agentes raiz criados e registrados com o Gemini Enterprise e hospedados no Vertex AI Agent Engine, 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 a endpoints particulares e capacidade de alcance de rede mais ampla. A rede VPC oferece uma plataforma para implementar controles de conectividade privada e segurança de rede para solicitações de agentes a outros agentes e ferramentas.
  • Subagentes: agentes especializados 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 tempo 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, e eles se conectam e interagem com elas usando a especificação do MCP.

Esse padrão de design multiagente de alto nível destaca os componentes de rede que estão em um sistema de IA multiagente. Ele pode oferecer suporte a vários tipos de padrões de roteamento de agente para agente. 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 multiagente 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 acesso aos projetos de serviço para usar esses recursos. Os projetos de serviço contêm os recursos de tempo de execução do agente, incluindo o Vertex AI Agent Engine, 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 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 vários 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 oferece à VPC compartilhada acessibilidade total às rotas do hub do NCC e conectividade aos pontos de acesso ao 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 a subagentes, ferramentas e serviços. O roteamento de rede VPC governa a capacidade de acesso 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 o seguinte:

  • Outras redes VPC por peering de rede VPC, dispositivos multi-NIC ou NCC.
  • Endpoints do Private Service Connect para acessar serviços do produtor.
  • Serviços gerenciados com endereços IP particulares, como o Cloud SQL.
  • Front-ends de 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 acessível pelo roteamento IP da rede VPC.
  • Outros agentes, ferramentas e serviços de suporte de IA.

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 Gemini Enterprise e entre o app e os agentes.

Conversa do usuário com os apps do Gemini Enterprise

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

Apps do Gemini Enterprise para agentes personalizados

Você registra agentes personalizados com o serviço de descoberta do Gemini Enterprise. Ao registrar um agente, o Gemini Enterprise mapeia o nome dele para um destino específico, seja o URI do recurso do Vertex AI Agent Engine 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 com o Gemini Enterprise, você pode implantar esse agente em qualquer lugar como um agente personalizado. Os agentes personalizados no Vertex AI Agent Engine 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 informações sobre 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 Vertex AI. O caminho de rede e os mecanismos de autorização variam de acordo com a plataforma de hospedagem usada:

  • Agentes personalizados no Vertex AI Agent Engine: o agente de serviço do Vertex AI Discovery Engine inclui as funções necessárias do Identity and Access Management (IAM) da Vertex AI para invocar recursos do Vertex AI Agent Engine como um recurso integrado. O sistema encaminha solicitações feitas ao serviço da API Vertex AI pela rede do Google como uma chamada de API interna.
  • Agentes de serviço personalizados no Cloud Run: os apps do Gemini Enterprise usam a identidade do agente de serviço do Discovery Engine da Vertex AI para fazer chamadas ao URL run.app estável registrado no card do agente. Para que o serviço do Cloud Run do agente de IA autorize essas chamadas, conceda 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 encaminhadas 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 Vertex AI Discovery Engine para fazer chamadas ao URL registrado no card do agente. O DNS público precisa 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 gke-l7-global-external-managed. Para aumentar a 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, conceda o papel do IAM Usuário do aplicativo 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 de 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 particular para plataformas de hospedagem de agentes

Depois que um usuário inicia uma solicitação para o app 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 Vertex AI Agent Engine, o Cloud Run e o GKE.

Ao escolher uma plataforma de hospedagem de agente, considere 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 com agentes.

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

  • Agentes personalizados no Vertex AI Agent Engine: as interfaces do Private Service Connect conectam os tempos de execução do Vertex AI Agent Engine à rede VPC. Você cria um anexo de rede em uma sub-rede da sua rede VPC e concede permissão ao Vertex AI Agent Engine para se conectar a ela. O tráfego enviado pelo Vertex AI Agent Engine aparece na rede VPC como se tivesse origem no endereço IP da sub-rede do anexo. A rede VPC então roteia o tráfego para o endereço IP de destino apropriado.
  • Agentes personalizados no Cloud Run: a saída direta da VPC 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 sido originado no endereço IP da sub-rede da saída da VPC direta. A rede VPC então roteia o tráfego para o endereço IP de destino adequado.
  • 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 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 sobre como gerenciar solicitações de entrada e saída da rede VPC para cada plataforma de hospedagem de agente. As considerações sobre a rede se aplicam à funcionalidade do agente raiz e do subagente.

Rede do Vertex AI Agent Engine

Esta seção descreve a rede particular para agentes raiz e subagentes hospedados no Vertex AI Agent Engine. Se você estiver usando o Vertex AI Agent Engine para hospedar seu agente raiz, implante o Gemini Enterprise e o Vertex AI Agent Engine no mesmo projeto.

O Vertex AI Agent Engine 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 Vertex AI Agent Engine para a rede VPC

O Vertex AI Agent Engine usa um projeto de locatário gerenciado pelo Google para saída de rede. A rede do locatário oferece conectividade para agentes com APIs do Google e saída da Internet pública, mas não é conectada diretamente às redes VPC do cliente por padrão.

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

Para implantar o egress da rede VPC do Vertex AI Agent Engine, consulte estes recursos:

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

Entrada do Vertex AI Agent Engine da rede VPC

As solicitações aos agentes que são executados no Vertex AI Agent Engine são feitas usando o endpoint de API do Vertex AI (aiplatform.googleapis.com). Para acessar os endpoints das APIs do Google usando caminhos de rede particulares 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 aos agentes precisam resolver o nome do host do endpoint de API do Vertex AI 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 privada gerenciada do Cloud DNS para googleapis.com resolve solicitações para a API Vertex AI. 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, pode ajudar a proteger o tráfego da sua rede VPC para o Vertex AI Agent Engine usando os seguintes produtos e recursos:

Outras considerações sobre a rede do Vertex AI Agent Engine

O tráfego de saída do Vertex AI Agent Engine que usa interfaces do Private Service Connect só pode ser encaminhado para intervalos de endereços IP RFC 1918 na rede VPC. Para intervalos de destino específicos que não podem ser roteados pela saída do Vertex AI Agent Engine, consulte Requisitos de intervalo de IP de 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 usam um endereço IP roteável na rede VPC.

Quando o Vertex AI Agent Engine é 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 Vertex AI Agent Engine é implantado com uma interface do Private Service Connect, a saída direta da Internet é desativada, independente do VPC Service Controls. Se você precisar que o agente acesse um destino que o Vertex AI Agent Engine 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. Você precisa configurar 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 Vertex AI Agent Engine ofereça suporte à resolução de consultas DNS do agente para o endereço particular 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 de saída do Vertex AI Agent Engine chega à rede VPC, ele pode alcançar qualquer destino de rede roteável pela rede VPC. Para informações sobre como limitar o escopo dos destinos de rede de saída disponíveis para agentes do Vertex AI Agent Engine, consulte a seção Cloud NGFW mais adiante neste documento.

Rede do Cloud Run

Esta seção descreve 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 à sua 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 direta de VPC. Com a saída VPC direta, as instâncias do Cloud Run se conectam diretamente à rede VPC compartilhada usando um endereço IP da sub-rede especificada ao implantar a saída 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 à rede VPC.

Essa configuração envia todo o tráfego pela rede VPC para 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 configuração adicional de peering de DNS é necessária. Os agentes hospedados no Cloud Run resolvem todas as zonas privadas do Cloud DNS e os nomes de host públicos.

Para informações sobre como proteger ainda mais os agentes e a rede VPC para 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 *.run.app estável para serviços do Cloud Run que executam cargas de trabalho de ferramentas ou agentes de IA. Esses endpoints são veiculados pelo mesmo ponto de entrada do GFE que veicula os serviços de API *.googleapis.com. O Cloud Run usa os mesmos caminhos de rede subjacentes que ativam a conectividade particular para o Acesso privado do Google e 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 privada gerenciada do Cloud DNS para o run.appURL resolve solicitações de serviços do Cloud Run. A rede VPC roteia a solicitação diretamente pela rede de produção do Google.

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

  • Redes VPC do projeto de serviço do Cloud Run.
  • A rede VPC compartilhada que hospeda o endpoint de saída direta de VPC.
  • 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 dentro do projeto de serviço ou do 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 chamados, o tráfego de fora do projeto de serviço do Cloud Run ou do ambiente de VPC compartilhada será tratado como externo. Esse tráfego inclui o de outros serviços do Google Cloud, como o Vertex AI Agent Engine e outros serviços do Cloud Run. Para atender à verificação de entrada interna do Cloud Run, esse tráfego precisa ser roteado de forma que pareça se originar de dentro da rede VPC do serviço de destino.

Para fornecer a atribuição de rede interna necessária, faça uma das seguintes ações:

  • Use 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 seu serviço do Cloud Run, usando um endereço IP privado na sua rede VPC.
  • Roteie o tráfego por um balanceador de carga de aplicativo interno colocado na sua rede VPC em frente ao serviço do Cloud Run. O balanceador de carga encaminha solicitações de outros serviços pela rede VPC para que atendam aos critérios de entrada internos.

Os balanceadores de carga de aplicativo internos com back-ends de grupo de endpoints de rede (NEG) sem servidor criam um recurso de VPC mapeado diretamente para um serviço do Cloud Run. Nesse modelo, o balanceador de carga encerra conexões TLS do cliente com um certificado de confiança. Os balanceadores de carga de aplicativo internos oferecem suporte a controles de segurança adicionais, incluindo 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 informações sobre como configurar os controles de entrada do Cloud Run, consulte estes recursos:

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

Se você usa um balanceador de carga de aplicativo interno para enviar tráfego da sua rede VPC para o Cloud Run, é possível 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 de ferramentas e agentes 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 oferecer eficiência operacional em escala. Ele pode se integrar 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 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, exponha com segurança um gateway externo com um endereço IP público e um nome DNS. O tráfego flui da saída do Gemini Enterprise para a rede de borda do Google, onde ele faz um trajeto otimizado até 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 oferecer um modelo abrangente de defesa em profundidade para proteger 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 gerenciamento e controle:

  • Autopilot: o Google automatiza toda a infraestrutura de cluster do GKE, incluindo o plano de controle, o provisionamento de nós, o reforço da proteção de 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 seleção de tipos de máquinas, gerenciamento de 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 fique isolado da exposição direta à Internet.
  • Redes autorizadas do mestre: restringem o acesso administrativo à API Kubernetes a intervalos de endereços IP específicos e confiáveis, o que protege o plano de controle contra mudanças de configuração não autorizadas. Proteja o endpoint 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 gatekeeper 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 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 ponta robusta, incluindo regras de firewall de aplicativos da Web (WAF) para ajudar a bloquear payloads maliciosos, proteção contra DDoS para garantir o tempo de atividade e limitação de taxa para evitar a exaustão do serviço.
  • Model Armor: criado especificamente para a segurança de LLMs, o Model Armor inspeciona e higieniza comandos e respostas em tempo real para evitar injeção de comandos e exfiltração de dados.
Isolamento de rede interna
  • Políticas de rede do Kubernetes: aplicam a comunicação granular de menor privilégio entre microsserviços. Por padrão, as políticas negam todo o tráfego, a menos que você 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 oferece os seguintes atributos:

  • O cluster do GKE usa intervalos de endereços IP de alias.
  • Os endereços IP do pod são reservados especificando o intervalo de IP do pod.
  • Os endereços IP do pod são nativamente acessí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 no 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 alcançar o destino usando o mesmo roteamento padrão da VPC, sujeito a regras de firewall.

É possível ajudar a proteger o tráfego que sai do cluster do GKE usando os seguintes produtos e serviços:

Entrada do GKE da rede VPC

Os serviços do Kubernetes fornecem 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 necessários de balanceamento de carga. Os grupos de endpoints de rede de back-end do o serviço são conectados para fornecer balanceamento de carga diretamente aos contêineres. Para expor um serviço internamente para tráfego originado da rede VPC, use as classes de gateway para balanceador de carga de aplicativo interno regional (gke-l7-rilb) ou balanceador de carga de aplicativo interno entre regiões (gke-l7-cross-regional-internal-managed-mc).

Os balanceadores de carga de aplicativo fornecem pontos de controle de segurança adicionais para proteger agentes e 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 baseada em IP e localização 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 os 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 rede VPC para o serviço do GKE por um gateway, poderá ajudar a 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 Entenda a segurança de rede no GKE.

Segurança de rede do agente

Para proteger a rede de um sistema de IA 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 com segurança. 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 alcançar os endpoints do agente, verificando todas as conexões de entrada ou saída para e de outros agentes e ferramentas.

O Cloud NGFW é um serviço de firewall distribuído integrado à estrutura da 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 baseada em IP com objetos de nome de domínio totalmente qualificado (FQDN), objetos de geolocalização e feeds do Google Threat Intelligence para bloquear endereços maliciosos conhecidos.
  • Cloud Next Generation Firewall Enterprise: oferece recursos de inspeção de aplicativos (L7) com descriptografia de TLS e recursos de 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 na rede VPC para impor uma política de firewall com base nas regras necessárias para segmentar a plataforma de hospedagem do agente usada.

  • Vertex AI Agent Engine: os agentes executados no Vertex AI Agent Engine 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 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 a correspondência de tráfego, use intervalos de endereços IP de origem e destino.
  • GKE: os clusters do GKE nativos de VPC atribuem aos pods endereços IP 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 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 então segmentar ou originar tráfego de nós com tags específicas. As regras de firewall também podem segmentar ou originar 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 restante é bloqueado por padrão. Essa implementação é realizada estruturando regras de firewall com regras ALLOW de alta prioridade para fluxos conhecidos e legítimos e uma regra DENY de baixa prioridade e abrangente. 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 ao tráfego de origem da sub-rede de anexação de rede do Vertex AI Agent Engine e da sub-rede de saída direta de VPC do Cloud Run.

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

  • Criar políticas 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 segmentam 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 a 1.000. Essas regras permitem precisamente o tráfego de rede necessário para que seus agentes de IA funcionem. Esse tráfego inclui 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 de anexação de rede do Vertex AI Agent Engine ou da sub-rede de saída direta da VPC do Cloud Run para os destinos desejados.
  • Regra DENY geral: 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 a possível exfiltração de dados ou o acesso a sites maliciosos. A política restringe os agentes hospedados para que eles se comuniquem apenas com endpoints aprovados, o que é crucial para manter o controle sobre cargas de trabalho autônomas.

Outras considerações sobre políticas 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 de IA multiagente usando recursos de nível pago:

  • Recursos padrão do Cloud NGFW:
    • Objetos FQDN para endpoints dinâmicos: os agentes de IA geralmente interagem com APIs externas, endpoints de modelos ou fontes de dados cujos endereços IP podem mudar. Para ter 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 compliance 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 a inteligência de ameaças do Google em filtros de saída para bloquear automaticamente a conexão de agentes com 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 com 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 lidam com dados sensíveis ou que estão expostos a riscos maiores, inspecione 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 TLS: para permitir que o mecanismo de inspeção analise o tráfego criptografado, ative a inspeção TLS. O uso da inspeção de TLS é crucial porque a maioria dos ataques modernos e da comunicação C2 são criptografados.

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

IAP

O IAP protege 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. A 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 principais precisam receber o papel do IAM de usuário do web app com proteção do 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 do app da Web protegido pelo IAP diretamente às contas de serviço de agentes que podem acessar outros agentes e ferramentas hospedados no recurso personalizado BackendConfig do GKE. 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 controlando estritamente o acesso às APIs do Google. Recomendamos que você implante um único macroperímetro que inclua todos os serviços compatíveis. Essa abordagem oferece a defesa mais robusta contra exfiltração. Para garantir a aplicação consistente da política 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 limites de projetos, considere as seguintes recomendações:

  • Implante um único perímetro do VPC Service Controls que abranja 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 configurações internas de entrada e autorização para bloquear todo o acesso público à Internet aos seus serviços do Cloud Run.

Os serviços do Cloud Run são protegidos pelo IAM. Os chamadores precisam ser autenticados e ter o papel do IAM Invocador do Cloud Run (roles/run.invoker) no serviço de destino. A função é verificada validando um token do cabeçalho de autorizaçã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 são tratadas como tráfego externo, o que força você a definir o acesso do Cloud Run como "Todos", deixando o serviço exposto à Internet pública.

  • O ingresso do Cloud Run all é compatível quando os dois itens a seguir são verdadeiros:
    • O VPC Service Controls não está ativado.
    • O Cloud Run e o Gemini Enterprise não estão no mesmo projeto.
  • Apenas 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 os seguintes controles de política para ajudar a garantir uma proteção abrangente:

  • Restringir as configurações de entrada permitidas: evite que os desenvolvedores implantem acidentalmente endpoints voltados ao público definindo a restrição de política da organização run.allowedIngress. Essa restrição se aplica apenas a novas implantações. Implantações anteriores podem não estar em conformidade. Recomendamos que você audite os serviços do Cloud Run no perímetro e reimplante ou atualize aqueles 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 possam ser inspecionadas pelas 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 toda revisão do Cloud Run use a saída VPC direta ou um conector de acesso VPC sem servidor. Essa restrição se aplica apenas a novas implantações. 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 aqueles que não atendem às configurações de entrada e saída necessárias.
  • Coloque imagens e serviços de contêineres no mesmo local: o repositório do Artifact Registry que contém as imagens de contêineres precisa estar no mesmo perímetro do serviço do Cloud Run. O pull de imagens entre perímetros é bloqueado automaticamente, a menos que você estabeleça regras explícitas de entrada e saída.
  • Gerenciar níveis de acesso: as regras da 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 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 segurança aprimorada para apps de IA. Os agentes de IA interagem com o Model Armor fazendo chamadas para limpar os comandos do usuário antes de serem enviados a um LLM e para limpar as respostas do modelo antes de serem retornadas ao usuário. O Model Armor verifica ativamente comandos e respostas de LLMs, o que oferece 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, configure um endpoint do Private Service Connect para o endpoint regional do Model Armor na sua rede VPC.

O Model Armor é um serviço regional acessado de forma particular por 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 ativar o acesso dos agentes, configure os seguintes componentes em todas as regiões em que o serviço Model Armor é necessário:

  1. Crie ou identifique uma sub-rede RFC 1918 na região da rede VPC em que o serviço Model Armor reside.
  2. Crie um endpoint regional na sub-rede RFC 1918.
  3. Crie uma zona privada 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 Vertex AI Agent Engine, estabeleça um peering de DNS do Vertex AI Agent Engine para a zona privada 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 Gemini Enterprise precisam ser iguais.

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 tempos de execução do serviço de back-end. As cargas de trabalho de agentes de IA envolvem grandes volumes de comunicação entre serviços que usam A2A, MCP e chamadas de API. 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, o tráfego pode ser filtrado para solicitações maliciosas e controlado com limites de taxa, e os ataques DDoS podem ser mitigados.

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

  • Cloud Run com balanceador de carga de aplicativo interno: proteja agentes e ferramentas 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 à NEG sem servidor para aplicar regras do WAF ao tráfego interno e à limitação de taxa. Para controlar as comunicações do agente, é possível definir 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 zonais. Use a API Kubernetes Gateway para aplicar o recurso GCPBackendPolicy com a política de segurança definida do Cloud Armor. Se você usa um balanceador de carga de aplicativo externo regional, o Cloud Armor oferece suporte a políticas de segurança de back-end com regras de WAF, controles baseados em endereço IP e geolocalização, 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 outras políticas de segurança de borda com a Proteção adaptativa do Google Cloud Armor e a Inteligência de ameaças do Google.

Proxy seguro da Web

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 para o tráfego de saída da Internet. Ele também atua como um proxy explícito para comunicações internas de serviço.

O Secure Web Proxy oferece suporte a 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. 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 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 sair para a Internet.

Usar o 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 Vertex AI Agent Engine, saída 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 é encapsulado no proxy, onde 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 controlada da Internet ou para destinos de rede particular que podem ser roteados pela rede VPC.

Roteamento de proxy explícito

A saída do Vertex AI Agent Engine 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 a interoperabilidade do Vertex AI Agent Engine, 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 pode ser acessado diretamente pelo Vertex AI Agent Engine. Em seguida, ele pode fazer proxy de qualquer conexão com destinos de endereços IP não roteáveis que estejam na rede VPC ou em redes conectadas.

Para oferecer suporte ao uso do Secure Web Proxy no modo de roteamento explícito pela plataforma de hospedagem do agente, configure estes recursos de rede:

  1. Crie ou identifique uma sub-rede RFC 1918 na rede VPC para hospedar o recurso do 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 Vertex AI Agent Engine, estabeleça um peering de DNS do Vertex AI Agent Engine para a zona privada 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 do 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) é definir 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 tempo de execução do agente até o 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 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 podem 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 nas 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 para todos os domínios particulares que os agentes precisam alcançar. Verifique se todos os destinos de domínio particular também estão incluídos no Cloud DNS.

O exemplo a seguir mostra uma implantação de proxy do Vertex AI Agent Engine de um objeto 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
    },
)

O Cloud Run aceita a definição de 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 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ícita em pods do GKE, defina um recurso ConfigMap que especifica 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 durante a 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 serviço de CA é necessário quando o Secure Web Proxy ou o Cloud NGFW são configurados para inspeção TLS. Quando a inspeção TLS está ativada e o destino de uma carga de trabalho usa TLS, o serviço de CA 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, inspeciona-o e aplica as políticas. Se as políticas permitirem o pacote, o serviço vai criptografá-lo novamente para o destino final. Você também pode 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 processa a assinatura do certificado de folha até que o certificado de CA raiz expire. Os certificados de CA raiz precisam ser atualizados para não expirar.

O serviço de AC oferece suporte a estes 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 TLS: o uso de uma CA particular é necessário para a inspeção TLS completa. Para descriptografar e analisar totalmente os payloads HTTPS, o dispositivo 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 serviço de CA pode gerar e assinar dinamicamente um certificado de representação específico do site solicitado. Quando o cliente tem o certificado de CA raiz privada 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, portanto, envia a solicitação. O proxy encerra a sessão TLS, descriptografa o pacote, inspeciona o conteúdo e aplica as políticas.

  • Distribuição de certificados: recursos de clientes internos, como agentes de IA que são executados no Vertex AI Agent Engine, no Cloud Run ou no GKE, precisam que o certificado de CA raiz privada seja 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.

    Recursos de servidor internos, como balanceadores de carga de aplicativo internos, precisam de certificados emitidos pela CA privada para atuarem como endpoints de servidor confiáveis e encerrarem sessões TLS do cliente. Os balanceadores de carga de aplicativo se integram às configurações de emissão do Gerenciador de certificados para automatizar a assinatura da solicitação de certificado pelo CA Service e a implantação 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 implantados em várias plataformas de hospedagem de tempo 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 Vertex AI Agent Engine, 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 de agente por um app do Gemini Enterprise.
  • O app Gemini Enterprise usa a infraestrutura do Google para se conectar a um agente raiz executado no GKE, no Cloud Run ou no Vertex AI Agent Engine.
  • 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 Vertex AI.
  • Os agentes raiz podem usar a infraestrutura do Google para se conectar a subagentes que são executados no Cloud Run ou no Vertex AI Agent Engine.
  • Os agentes raiz podem usar endereços IP particulares para se conectar a subagentes que são executados no Vertex AI Agent Engine, no Cloud Run e no GKE. Essas conexões precisam ser roteadas por uma rede VPC.
  • Os agentes raiz e os subagentes podem se conectar a servidores MCP executados no Cloud Run ou no GKE. Os agentes que se conectam aos servidores do MCP podem usar a infraestrutura do Google ou uma rede VPC. Os servidores MCP oferecem 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 tempo de execução e os controles de segurança necessários para interações A2A seguras. Essas informações servem como padrão arquitetônico para estabelecer conectividade particular e implementar as defesas multicamadas 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
Vertex AI Agent Engine (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 Vertex AI Agent Engine (interno)

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

Agente de destino (caminho de dados) Controle de segurança
Vertex AI Agent Engine (interno)
Cloud Run (interno)

Agente de origem do Vertex AI Agent Engine (interface do Private Service Connect)

A tabela a seguir fornece recursos para ajudar você a proteger o tráfego quando o Vertex AI Agent Engine é 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 GoogleAPIs)
Acesso ao Cloud Run (NEG sem servidor)
GKE
Internet pela rede VPC

Agente de origem (interno) do Cloud Run

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 viaja diretamente pela infraestrutura do Google. Nesses caminhos, nenhuma rede VPC está envolvida.

Agente de destino (caminho de dados) Controle de segurança
Vertex AI Agent Engine (interno)
Cloud Run (interno)

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

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 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
Private Service Connect do Vertex AI Agent Engine para APIs do Google

Segurança da conexão do 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 tempos de execução do agente e os servidores do MCP. Para agentes de origem no Vertex AI Agent Engine, 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
    • Proxy seguro da Web
  • 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: