Patrones de redes privadas de varios agentes en Google Cloud

Last reviewed 2026-04-16 UTC

En este documento, se proporciona orientación para ayudarte a diseñar una infraestructura de redes privadas que admita una app de Gemini Enterprise de varios agentes y accesible de forma pública con conexiones privadas entre agentes, subagentes y herramientas. El diseño de la red proporciona conexiones privadas para los agentes alojados en Vertex AI Agent Engine, Cloud Run, Google Kubernetes Engine (GKE), centros de datos locales o en otras nubes. El diseño también admite la conectividad con agentes que se ejecutan en ubicaciones de Internet.

Los sistemas de IA de agentes múltiples suelen involucrar datos sensibles o propietarios de la organización. Las redes privadas te permiten evitar exponer este tráfico a la Internet pública. Este diseño utiliza Google Cloud infraestructura de red, recursos de red de nube privada virtual (VPC) y conectividad privada a entornos locales o redes de múltiples nubes.

En el diseño que se describe en este documento, los agentes se comunican con otros agentes y con herramientas a través del protocolo Agent2Agent (A2A) y el Protocolo de contexto del modelo (MCP). Las comunicaciones se hacen privadas al enrutarlas a través de una red de VPC. Para trasladar el tráfico dentro y fuera de la red de VPC, este diseño usa una combinación de extremos de Private Service Connect, interfaces de Private Service Connect y salida directa de VPC de Cloud Run. Cloud Next Generation Firewall (Cloud NGFW) rige el tráfico que pasa por la red de VPC. Las capas de seguridad adicionales proporcionan una salida controlada a Internet a través de Secure Web Proxy y políticas de acceso a los servicios de API a través de un perímetro de Controles del servicio de VPC.

El público objetivo de este documento incluye arquitectos, desarrolladores y administradores que compilan y administran apps y la infraestructura de IA en la nube. En este documento, se supone que tienes conocimientos básicos sobre los agentes y modelos de IA, y que estás familiarizado con los Google Cloud conceptos de redes.

Patrón de diseño multiagente

Una app de Gemini Enterprise con varios agentes requiere un agente personalizado que actúe como organizador o agente raíz para las conexiones con herramientas y subagentes. Para implementar conexiones privadas a herramientas y subagentes alojados enGoogle Cloud o de forma local, el diseño usa una red de VPC con direcciones IP privadas. El agente raíz se aloja en la infraestructura de Google con Agent Engine, Cloud Run o GKE. El patrón de diseño multiagente destaca estas interacciones:

  1. App de Gemini Enterprise que interactúa con agentes raíz personalizados. Las apps de Gemini Enterprise presentan una interfaz de usuario administrada con funciones de seguridad integradas que exponen la funcionalidad del agente personalizado. Los agentes raíz personalizados se registran en Gemini Enterprise y están disponibles en las apps para los usuarios finales. El agente raíz personalizado actúa como organizador de flujo de trabajo de nivel superior y delega tareas especializadas a los subagentes. Esta arquitectura usa agentes raíz personalizados alojados en Vertex AI Agent Engine, Cloud Run o GKE.
  2. Agentes raíz que interactúan con subagentes y herramientas. El núcleo del flujo de trabajo y la lógica empresarial del sistema de IA residen en el agente raíz y en los subagentes especializados. La flexibilidad del framework, el tiempo de ejecución y la plataforma de hosting del agente permite diferentes opciones para conectar agentes raíz a subagentes y herramientas a través de la red de VPC. Si usas redes de VPC para esta parte de la arquitectura, los agentes pueden usar rutas de redes privadas que definas y que expongan otros extremos privados, controles de seguridad empresariales y una mayor accesibilidad a la red.

Descripción general de alto nivel de una arquitectura de redes de varios agentes.

La arquitectura incluye los siguientes componentes:

  • App de Gemini Enterprise: Es la interfaz que permite a los usuarios acceder a una interfaz de chat en la app y, luego, interactuar con el sistema de IA multiagente. Los usuarios pueden acceder a las apps de Gemini Enterprise a través de Internet pública o de forma privada a través de conexiones híbridas.
  • Agentes personalizados: Son agentes raíz que se compilan y registran con Gemini Enterprise, y que se alojan en Vertex AI Agent Engine, Cloud Run o GKE. Estos agentes raíz funcionan como organizadores que delegan tareas a subagentes.
  • Red de VPC: Es un recurso que controlas para proporcionar a los agentes conectividad de red IP a extremos privados y un mayor alcance de la red. La red de VPC proporciona una plataforma para implementar la conectividad privada y los controles de seguridad de red para las solicitudes de agentes a otros agentes y herramientas.
  • Subagentes: Son agentes especializados que se activan con el flujo de trabajo del agente raíz. Los subagentes se comunican a través del protocolo A2A, que permite la interoperabilidad entre agentes independientemente del lenguaje de programación y el tiempo de ejecución.
  • Herramientas: Son sistemas remotos que exponen servicios como APIs, fuentes de datos y funciones de flujo de trabajo. Estas herramientas recuperan datos y realizan acciones o transacciones para los agentes. Las herramientas son externas a los agentes, y estos se conectan e interactúan con las herramientas a través de la especificación del MCP.

Este arquetipo de diseño multiagente de alto nivel destaca los componentes de redes que se encuentran en un sistema de IA multiagente. Puede admitir muchos tipos diferentes de patrones de enrutamiento de agente a agente. Para obtener información sobre otros patrones de diseño de sistemas de IA, consulta Elige un patrón de diseño para tu sistema de IA de agentes.

VPC compartida

El patrón de diseño de varios agentes usa la VPC compartida para centralizar la autoridad y la responsabilidad de las redes y la seguridad. Este diseño proporciona a los desarrolladores entornos que ayudan a satisfacer las necesidades de seguridad de una organización. Te recomendamos que uses la VPC compartida para centralizar y simplificar la configuración de tu red y seguridad.

En una arquitectura de VPC compartida, un proyecto host contiene los recursos de red compartidos, incluidas las redes de VPC, los Cloud Routers, las subredes, los firewalls y Cloud DNS. Los administradores pueden otorgar acceso a los proyectos de servicio para usar estos recursos. Los proyectos de servicio contienen los recursos de tiempo de ejecución del agente, incluidos Vertex AI Agent Engine, Cloud Run, GKE, Gemini Enterprise y balanceadores de cargas específicos de la app.

La VPC compartida aplica un límite claro entre los roles de administrador de red y seguridad, y los roles de desarrollador de apps con IA:

  • Los administradores de red y seguridad controlan la infraestructura principal, como el enrutamiento de VPC, las subredes, el peering de DNS y las políticas de firewall.
  • Los desarrolladores de apps con IA compilan agentes en proyectos de servicio adjuntos sin tener permisos para modificar la infraestructura de red subyacente.

Cuando centralizas las implementaciones de red y seguridad en un proyecto host, creas un solo punto de administración para la comunicación entre agentes y entre agentes y servicios. Este diseño simplifica la aplicación de políticas de seguridad en muchos proyectos de servicio diferentes y garantiza una conectividad coherente.

Puedes incorporar tu red de VPC compartida a una Red Multinube usando radios de VPC de Network Connectivity Center (NCC) para agregar la red de VPC compartida como una red de VPC de carga de trabajo. Esta implementación proporciona a la VPC compartida accesibilidad total a las rutas del concentrador de NCC y conectividad a los puntos de acceso a servicios desde otros radios.

Las solicitudes que se inician desde agentes raíz personalizados usan una red de VPC privada administrada por el cliente para proporcionar rutas de red seguras a subagentes, herramientas y servicios. El enrutamiento de la red de VPC rige la accesibilidad a los extremos privados. Las políticas de Cloud NGFW que se aplican a la red de VPC rigen el acceso a la red.

Los agentes obtienen acceso seguro a las rutas de red de VPC privadas, incluida la conectividad a los siguientes elementos:

  • Otras redes de VPC a través del intercambio de tráfico entre redes de VPC, dispositivos con varias NIC o NCC
  • Son los extremos de Private Service Connect para acceder a los servicios del productor.
  • Servicios administrados que tienen direcciones IP privadas, como Cloud SQL
  • Son los extremos frontales del balanceador de cargas interno y los recursos de Compute Engine.
  • APIs de Google a través del Acceso privado a Google o de Private Service Connect
  • Internet, controlado a través de Secure Web Proxy.
  • Destinos híbridos y de múltiples nubes con Cloud Interconnect, Cloud VPN, dispositivo de router o SD-WAN.
  • Cualquier destino de extremo al que se pueda acceder a través del enrutamiento de IP de la red de VPC
  • Otros agentes, herramientas y servicios de asistencia basados en IA

Para obtener más información sobre la VPC compartida, consulta los siguientes recursos:

Conexión en red de Gemini Enterprise

Las apps de Gemini Enterprise son recursos administrados que operan en un entorno alojado fuera de la red de VPC, pero dentro de la red de Google. En las siguientes secciones, se describe la configuración de redes entre el usuario y la app de Gemini Enterprise, y entre la app y los agentes.

Chats de usuarios con las apps de Gemini Enterprise

Los usuarios chatean con la app de Gemini Enterprise a través de una app basada en el navegador que envía solicitudes a las APIs y los servicios de Google. Para habilitar la conectividad privada del usuario, puedes configurar las URLs de las APIs de Google para que se resuelvan en rangos de direcciones IP privadas que se enrutan a través de tu red de VPC. Para obtener más información, consulta Cómo configurar el acceso a la IU privada.

Apps de Gemini Enterprise a agentes personalizados

Registras agentes personalizados con el servicio de descubrimiento de Gemini Enterprise. Cuando registras un agente, Gemini Enterprise asigna el nombre del agente a un destino específico, ya sea el URI del recurso de Vertex AI Agent Engine o la URL del agente de A2A. Las apps de Gemini Enterprise tienen una interfaz de chat integrada que se llama el asistente. Cuando un usuario especifica un agente con @agent_name o cuando el asistente decide delegar, la app busca el agente en el registro para encontrar el extremo asociado.

Cuando registras un agente raíz con Gemini Enterprise, puedes implementarlo en cualquier lugar como un agente personalizado. Los agentes personalizados en Vertex AI Agent Engine y en Cloud Run pueden usar rutas de red privadas existentes sin configurar recursos de redes adicionales. Para implementar un agente personalizado en GKE, debes exponer el servicio con una puerta de enlace externa. Para obtener información sobre cómo configurar la puerta de enlace externa para que sea más segura, consulta Redes de GKE más adelante en este documento.

Para realizar solicitudes a agentes personalizados, Gemini Enterprise usa la identidad de la cuenta de servicio de Discovery Engine de Vertex AI. La ruta de acceso a la red y los mecanismos de autorización difieren según la plataforma de hosting que uses:

  • Agentes personalizados en Vertex AI Agent Engine: El agente de servicio de Vertex AI Discovery Engine incluye los roles necesarios de Identity and Access Management (IAM) de Vertex AI para invocar recursos de Vertex AI Agent Engine como una función integrada. El sistema enruta las solicitudes que se realizan al servicio de la API de Vertex AI a través de la red de Google como una llamada a la API interna.
  • Agentes personalizados en Cloud Run: Las apps de Gemini Enterprise usan la identidad del agente de servicio de Vertex AI Discovery Engine para realizar llamadas a la URL estable run.app que se registra desde la tarjeta del agente. Para que el servicio de Cloud Run del agente de IA autorice estas llamadas, debes otorgar el rol de IAM de Cloud Run Invoker (roles/run.invoker) al agente de servicio de Discovery Engine. Las solicitudes a Cloud Run se enrutan a través de la red de producción de Google al Google Front End (GFE) para la entrada de Cloud Run.

  • Agentes personalizados en GKE: Las apps de Gemini Enterprise usan la identidad del agente de servicio de Vertex AI Discovery Engine para realizar llamadas a la URL registrada desde la tarjeta del agente. El DNS público debe poder resolver el nombre de host en una dirección IP externa que administre la puerta de enlace. Te recomendamos que uses el balanceador de cargas gke-l7-regional-external-managed o el balanceador de cargas gke-l7-global-external-managed. Para mayor seguridad, te recomendamos que Gemini Enterprise llame a un agente de A2A alojado en GKE con Identity-Aware Proxy (IAP). Para que IAP autorice estas llamadas, debes otorgar el rol de IAM Usuario de aplicación web protegida con IAP (roles/iap.httpsResourceAccessor) al agente de servicio de Discovery Engine. La red de producción de Google enruta las solicitudes a GKE y al GFE para el ingreso del balanceador de cargas de aplicaciones externo.

    Para proteger Ingress de GKE de Gemini Enterprise, consulta las secciones IAP y Google Cloud Armor más adelante en este documento.

Redes privadas para plataformas de alojamiento de agentes

Después de que un usuario inicia una solicitud a la app de Gemini Enterprise, los agentes raíz personalizados inician solicitudes a los subagentes y las herramientas. Las plataformas de alojamiento de agentes personalizados proporcionan la interfaz entre Gemini Enterprise y tus redes de VPC. Las plataformas de alojamiento para tus agentes y herramientas alojados en contenedores son Vertex AI Agent Engine, Cloud Run y GKE.

Cuando elijas una plataforma de hosting de agentes, debes tener en cuenta los patrones de redes privadas, los controles de seguridad, el control de administración, el nivel de personalización y el cumplimiento de seguridad de cada plataforma. Para obtener más información sobre cómo seleccionar una plataforma de hosting de agentes de IA, consulta Elige modelos y la infraestructura para tu aplicación de IA generativa y Elige los componentes de la arquitectura de IA de agentes.

Estableces la conectividad privada de la VPC a través de diferentes mecanismos según la plataforma de alojamiento de agentes que uses:

  • Agentes personalizados en Vertex AI Agent Engine: Las interfaces de Private Service Connect conectan los tiempos de ejecución de Vertex AI Agent Engine a la red de VPC. Crea una vinculación de red en una subred de tu red de VPC y otorga permiso a Vertex AI Agent Engine para que se vincule a ella. El tráfico que se envía desde Vertex AI Agent Engine aparece en la red de VPC como si se hubiera originado en la dirección IP de la subred de la vinculación. Luego, la red de VPC enruta el tráfico a la dirección IP de destino adecuada.
  • Agentes personalizados en Cloud Run: La salida de VPC directa de Cloud Run conecta las instancias de servicio de Cloud Run a la red de VPC. La red de VPC que se especifica cuando se implementa un servicio de Cloud Run puede ser del proyecto de servicio de Cloud Run o de su proyecto host de la VPC compartida. El tráfico que se envía desde Cloud Run aparece en la red de VPC como si se hubiera originado en la dirección IP de la subred de la salida de VPC directa. Luego, la red de VPC enruta el tráfico a la dirección IP de destino adecuada.
  • Agentes personalizados en GKE: Los clústeres de GKE residen directamente en la red de VPC y usan direcciones IP de subred locales. De forma predeterminada, el tráfico de salida de GKE usa la dirección IP del Pod como dirección IP de origen. Si configuras el enmascaramiento, el tráfico de salida de GKE usa la dirección IP del nodo como la dirección IP de origen. La red de VPC enruta todo el tráfico de salida de GKE.

En las siguientes secciones, se proporciona orientación adicional para administrar las solicitudes de entrada y salida hacia la red de VPC y desde ella para cada plataforma de hosting de agentes. Las consideraciones de red se aplican tanto a la funcionalidad del agente raíz como a la del subagente.

Redes de Vertex AI Agent Engine

En esta sección, se describe la conexión en red privada para los agentes raíz y los subagentes alojados en Vertex AI Agent Engine. Si usas Vertex AI Agent Engine para alojar tu agente raíz, debes implementar Gemini Enterprise y Vertex AI Agent Engine en el mismo proyecto.

Vertex AI Agent Engine aloja contenedores en la infraestructura de Google fuera de tu red de VPC. Para habilitar la conectividad privada a otros agentes, puedes conectar tu agente a tu red de VPC con los siguientes métodos:

Para permitir solicitudes entre tus agentes y otros agentes, configura ambas conexiones anteriores.

Salida de Vertex AI Agent Engine a la red de VPC

Vertex AI Agent Engine usa un proyecto de arrendatario administrado por Google para la salida de red. La red de arrendatario proporciona conectividad para que los agentes accedan a las APIs de Google y para la salida a Internet pública, pero de forma predeterminada no está conectada directamente a las redes de VPC del cliente.

Para conectar agentes a recursos que se encuentran dentro de tu red de VPC, Vertex AI Agent Engine usa interfaces de Private Service Connect. Vertex AI Agent Engine implementa una interfaz de red en el proyecto del arrendatario que se conecta a un recurso de adjunto de red en tu proyecto. Esta conexión crea una ruta de datos segura entre el tiempo de ejecución de Vertex AI Agent Engine y la red de VPC. Cuando configuras una interfaz de Private Service Connect en tu proyecto de Vertex AI Agent Engine, el sistema enruta todo el tráfico del agente que no está destinado a las APIs de Google a la red de VPC.

Para implementar el tráfico de salida de la red de VPC de Vertex AI Agent Engine, consulta los siguientes recursos:

Para proteger aún más los agentes y la red de VPC para la salida del motor de agentes de Vertex AI, consulta estas secciones más adelante en este documento:

Entrada de Vertex AI Agent Engine desde la red de VPC

Las solicitudes a los agentes que se ejecutan en Vertex AI Agent Engine se realizan a través del extremo de API de Vertex AI (aiplatform.googleapis.com). Para acceder a los extremos de las APIs de Google a través de rutas de red privadas desde la red de VPC, usa el Acceso privado a Google o los extremos de Private Service Connect para las APIs de Google.

Los usuarios privados que realizan consultas a los agentes deben resolver el nombre de host del extremo de API de Vertex AI en el rango de direcciones IP privadas para el Acceso privado a Google o en la dirección IP del extremo de Private Service Connect para las APIs de Google. Una zona privada administrada de Cloud DNS paragoogleapis.com resuelve solicitudes para la API de Vertex AI. La red de VPC enruta la solicitud directamente a través de la red de producción de Google.

Si usas el Acceso privado a Google o Private Service Connect para las APIs de Google, puedes ayudar a proteger el tráfico desde tu red de VPC a Vertex AI Agent Engine con los siguientes productos y funciones:

Consideraciones adicionales sobre la red de Vertex AI Agent Engine

El tráfico de salida de Vertex AI Agent Engine que usa interfaces de Private Service Connect solo puede enrutarse a rangos de direcciones IP de RFC 1918 en la red de VPC. Para conocer los rangos de destino específicos a los que no se puede enrutar el tráfico de salida de Vertex AI Agent Engine, consulta los requisitos del rango de IP de la subred. Para llegar a destinos con rangos de direcciones IP no enrutables, usa una configuración de proxy explícita en los agentes y, luego, implementa recursos de proxy que usen una dirección IP enrutable en la red de VPC.

Cuando Vertex AI Agent Engine se implementa sin una interfaz de Private Service Connect, tiene acceso a Internet de forma predeterminada. Para protegerte contra el robo de datos, inhabilita el acceso predeterminado habilitando los Controles del servicio de VPC.

Cuando se implementa Vertex AI Agent Engine con una interfaz de Private Service Connect, se inhabilita la salida directa a Internet, independientemente de los Controles del servicio de VPC. Si necesitas que tu agente acceda a un destino al que Vertex AI Agent Engine no puede llegar normalmente, como Internet, haz lo siguiente:

  1. Configura Secure Web Proxy en una subred de RFC 1918 de tu red de VPC. Debes configurar el proxy en el modo de enrutamiento de proxy explícito.
  2. Crea un registro DNS de Cloud DNS para el nombre de host de Secure Web Proxy.
  3. Configura el intercambio de tráfico de DNS para que Vertex AI Agent Engine admita la resolución de consultas de DNS del agente a la dirección privada del Secure Web Proxy en la red de VPC.
  4. Cuando implementes agentes, haz lo siguiente:
    1. Define variables de entorno para usar el proxy explícito. Para ello, especifica el nombre de host y el puerto de Secure Web Proxy.
    2. Si accedes a un destino privado, configura una zona de DNS privada para ese destino.

Una vez que el tráfico de salida de Vertex AI Agent Engine llega a la red de VPC, puede alcanzar cualquier destino de red al que se pueda enrutar la red de VPC. Para obtener información sobre cómo limitar el alcance de los destinos de red de salida disponibles para los agentes de Vertex AI Agent Engine, consulta la sección Cloud NGFW más adelante en este documento.

Redes de Cloud Run

En esta sección, se describen las redes privadas para los agentes raíz y los subagentes alojados en Cloud Run. Cloud Run aloja contenedores en la infraestructura de Google fuera de tu red de VPC. Para habilitar la conectividad privada a otros agentes, puedes conectar tu agente a tu red de VPC con los siguientes métodos:

Para permitir solicitudes entre tus agentes y otros agentes, configura ambas conexiones anteriores.

Salida de Cloud Run a la red de VPC

Para iniciar conexiones de Cloud Run en una red de VPC, te recomendamos que uses la salida de VPC directa. Con la salida de VPC directa, las instancias de Cloud Run se conectan directamente a la red de VPC compartida con una dirección IP de la subred que especificas cuando implementas la salida de VPC directa.

Cuando configures la salida de VPC directa, haz lo siguiente:

  1. Configura la subred de destino con el Acceso privado a Google habilitado.
  2. Configura el enrutamiento del tráfico para enrutar todo el tráfico a la red de VPC.

Esta configuración envía todo el tráfico a través de la red de VPC para garantizar la privacidad y envía solicitudes de Cloud Run a otras APIs de Google a través de la red interna de Google.

Todas las consultas de DNS de Cloud Run usan la política y las zonas de Cloud DNS asociadas a la red de VPC. No se requiere ninguna configuración adicional del intercambio de tráfico de DNS. Los agentes alojados en Cloud Run resuelven todas las zonas privadas de Cloud DNS y los nombres de host públicos.

Para obtener información sobre cómo proteger aún más los agentes y la red de VPC para el tráfico de salida de Cloud Run, consulta estas secciones más adelante en este documento:

Entrada de Cloud Run desde la red de VPC

Cloud Run es una plataforma administrada por Google que opera en un entorno fuera de la red de VPC. Este entorno aloja el extremo de URL *.run.app estable para los servicios de Cloud Run que ejecutan cargas de trabajo de herramientas o agentes de IA. Estos extremos se publican desde el mismo punto de entrada de GFE que publica los servicios de la API de *.googleapis.com. Cloud Run usa las mismas rutas de red subyacentes que habilitan la conectividad privada para el Acceso privado a Google y para Private Service Connect para las APIs de Google.

Los usuarios privados de la red de VPC que realizan consultas a agentes o herramientas deben resolver el nombre de host run.app en el rango de direcciones IP privadas para el Acceso privado a Google o en la dirección IP del extremo de Private Service Connect para las APIs de Google. Una zona de Cloud DNS administrada privada para la run.app URL resuelve solicitudes para los servicios de Cloud Run. La red de VPC enruta la solicitud directamente a través de la red de producción de Google.

Si configuras la entrada de Cloud Run como Interna, restringes el acceso a tu servicio, ya que solo se permiten las solicitudes de fuentes internas verificadas. Las fuentes aprobadas incluyen las siguientes:

  • Son las redes de VPC del proyecto de servicio de Cloud Run.
  • Es la red de VPC compartida que aloja el extremo de salida de VPC directa.
  • Recursos que se encuentran dentro del mismo perímetro de Controles del servicio de VPC
  • Balanceadores de cargas de aplicaciones internos en la red de VPC
  • Servicios de Google, como Cloud Scheduler y Pub/Sub, que se encuentran dentro del proyecto de servicio o el perímetro de los Controles del servicio de VPC

Si no usas un perímetro común de Controles del servicio de VPC para abarcar los servicios de llamada y los llamados, el tráfico que provenga de fuera del proyecto de servicio de Cloud Run o del entorno de VPC compartida se tratará como externo. Este tráfico incluye el de otros servicios de Google Cloud, como Vertex AI Agent Engine y otros servicios de Cloud Run. Para satisfacer la verificación de entrada interna de Cloud Run, este tráfico debe enrutarse de manera que parezca originarse dentro de la red de VPC del servicio de destino.

Para proporcionar la atribución de red interna necesaria, puedes hacer lo siguiente:

  • Usa extremos de Private Service Connect para permitir que los servicios en otros proyectos o VPCs se conecten a las APIs y los servicios de Google, incluido tu servicio de Cloud Run, con una dirección IP privada dentro de tu red de VPC.
  • Enruta el tráfico a través de un balanceador de cargas de aplicaciones interno ubicado dentro de tu red de VPC delante de tu servicio de Cloud Run. El balanceador de cargas canaliza las solicitudes de otros servicios a través de la red de VPC para que cumplan con los criterios de entrada internos.

Los balanceadores de cargas de aplicaciones internos con backends de grupo de extremos de red (NEG) sin servidores crean un recurso de VPC que se asigna directamente a un servicio de Cloud Run. En este modelo, el balanceador de cargas finaliza las conexiones TLS del cliente con un certificado de confianza. Los balanceadores de cargas de aplicaciones internos admiten controles de seguridad adicionales, incluidas las políticas de seguridad de backend de Cloud Armor y políticas de autorización adicionales.

De forma predeterminada, el acceso a todos los servicios de Cloud Run requiere autenticación de IAM. Te recomendamos que uses una identidad por servicio y que otorgues a la entidad el rol de IAM de invocador de Cloud Run (roles/run.invoker).

Para obtener información sobre cómo configurar los controles de entrada de Cloud Run, consulta los siguientes recursos:

Si usas el Acceso privado a Google o los extremos de Private Service Connect para las APIs de Google para enviar tráfico desde tu red de VPC a Cloud Run, puedes proteger ese tráfico con los siguientes productos y funciones:

Si usas un balanceador de cargas de aplicaciones interno para enviar tráfico desde tu red de VPC a Cloud Run, puedes proteger ese tráfico con los siguientes productos y funciones:

Herramientas de redes de GKE

En esta sección, se describen las redes para los agentes basados en GKE.

GKE y Gemini Enterprise

Como host para herramientas y agentes de IA, GKE ofrece una plataforma altamente personalizable para los controles de red y seguridad. Un sistema de IA de agentes múltiples implementado en GKE puede proporcionar eficiencia operativa a gran escala. Se puede integrar estrechamente con otras apps de Kubernetes y arquitecturas de microservicios más grandes.

Los clústeres de GKE son nodos de VM de Compute Engine que se ejecutan dentro de una subred de la red de VPC. Las apps de Gemini Enterprise son recursos administrados que operan en un entorno alojado fuera de la red de VPC. Para permitir que las apps de Gemini Enterprise llamen a agentes personalizados alojados en GKE, debes exponer de forma segura una puerta de enlace externa con una dirección IP pública y un nombre de DNS. El tráfico fluye desde la salida de Gemini Enterprise a la red perimetral de Google, donde toma una ruta optimizada hacia el balanceador de cargas externo de GKE.

Es importante proteger el extremo de GKE con una autenticación y autorización sólidas, Cloud Armor y permisos limitados. Para proporcionar un modelo integral de defensa en profundidad que proteja los agentes de IA que se ejecutan en GKE, considera los controles de seguridad que se describen en las siguientes secciones.

Modo de operación de GKE

GKE ofrece estos modos de operación para equilibrar la administración y el control:

  • Autopilot: Google automatiza toda la infraestructura del clúster de GKE, incluido el plano de control, el aprovisionamiento de nodos, el refuerzo de la seguridad y el escalamiento.
  • Estándar: Google administra el plano de control. Conservas la responsabilidad total de las configuraciones del grupo de nodos, como la selección de tipos de máquinas, la administración de imágenes del SO y el escalamiento manual.
Endurecimiento de la infraestructura y el plano de control
  • Clústeres privados de GKE: Aprovisionan nodos sin direcciones IP públicas, lo que garantiza que el entorno de ejecución esté aislado de la exposición directa a Internet.
  • Redes autorizadas de instancia principal: Restringen el acceso administrativo a la API de Kubernetes a rangos de direcciones IP específicos y de confianza, lo que refuerza el plano de control contra cambios de configuración no autorizados. Protege el extremo de DNS para la API de Kubernetes con IAM y los Controles del servicio de VPC de Google Cloud.
Identidad y acceso (de confianza cero)
  • IAP: Actúa como un guardián de acceso a nivel del balanceador de cargas. Garantiza que solo los usuarios autenticados con los permisos de IAM correctos puedan acceder al extremo del agente. Este enfoque cambia de manera eficaz el perímetro de seguridad de la red al usuario individual y al contexto de su dispositivo.
Protección de bordes y administración del tráfico
  • Cloud Armor: Proporciona seguridad perimetral sólida, incluidas reglas de firewall de aplicación web (WAF) para ayudar a bloquear cargas útiles maliciosas, protección contra DSD para garantizar el tiempo de actividad y límite de frecuencia para evitar el agotamiento del servicio.
  • Model Armor: Model Armor, diseñado específicamente para la seguridad de los LLM, inspecciona y depura las instrucciones y respuestas en tiempo real para evitar la inyección de instrucciones y el robo de datos.
Aislamiento de la red interna
  • Políticas de red de Kubernetes: Aplican la comunicación detallada con privilegios mínimos entre microservicios. De forma predeterminada, las políticas rechazan todo el tráfico, a menos que lo permitas de forma explícita, lo que evita el movimiento lateral dentro del clúster.

Salida de GKE a la red de VPC

La red de VPC direcciona las conexiones salientes de los agentes alojados en GKE. El modo de red predeterminado del clúster de GKE es nativo de la VPC, que proporciona los siguientes atributos:

  • El clúster de GKE usa rangos de direcciones IP de alias.
  • Las direcciones IP del Pod se reservan especificando el rango de IP del Pod.
  • Las direcciones IP del Pod se pueden enrutar de forma nativa dentro de la red de VPC del clúster y otras redes de VPC conectadas.

Si un Pod de agente se comunica con un Pod de subagente en el mismo nodo, el tráfico se enruta de forma local dentro del espacio de nombres de red del nodo. Si el Pod del agente de destino se encuentra en un nodo diferente dentro del clúster, el tráfico se enruta a través de la tabla de enrutamiento de la red de VPC. Para que un Pod de agente se comunique con otros recursos de la VPC, como balanceadores de cargas o extremos de Private Service Connect, puede llegar al destino con el mismo enrutamiento estándar de la VPC, sujeto a las reglas de firewall.

Puedes proteger el tráfico que sale de tu clúster de GKE con los siguientes productos y servicios:

Entrada de GKE desde la red de VPC

Los servicios de Kubernetes proporcionan acceso a los recursos de GKE. Para un sistema de IA con varios agentes, te recomendamos que uses una puerta de enlace de GKE o una puerta de enlace de inferencia de GKE. La puerta de enlace proporciona capacidades mejoradas con control de tráfico, separación operativa de recursos e integraciones de seguridad. Sin embargo, hay otras opciones de servicios de entrada disponibles según los requisitos del sistema.

El recurso Gateway crea un balanceador de cargas de aplicaciones y aprovisiona todos los componentes de balanceo de cargas necesarios. Los grupos de extremos de red de backend del servicio están conectados para proporcionar balanceo de cargas directamente a los contenedores. Para exponer un servicio de forma interna para el tráfico que proviene de la red de VPC, usa las clases de Gateway para el balanceador de cargas de aplicaciones interno regional (gke-l7-rilb) o el balanceador de cargas de aplicaciones interno entre regiones (gke-l7-cross-regional-internal-managed-mc).

Los balanceadores de cargas de aplicaciones proporcionan puntos de control de seguridad adicionales para proteger los agentes y las herramientas de IA alojados en clústeres de GKE:

  • Cloud Armor: Protege los servicios adjuntando una política de seguridad de Cloud Armor a los servicios de backend que administra Gateway. Proporciona detección de WAF, filtrado basado en IP y ubicación geográfica, protección contra DSD y limitación de frecuencia antes de que el tráfico llegue al clúster de GKE o al IAP.
  • IAP: Se habilita en el servicio de backend para controlar el acceso a las apps con credenciales de IAM. IAP aplica políticas de acceso de confianza cero. IAP autentica y autoriza a los agentes de IA que acceden a los recursos del clúster, incluidas las apps de Gemini Enterprise, los agentes personalizados y los recursos externos. Requiere que los llamadores tengan una identidad autenticada por IAM y que tengan permiso autorizado para acceder al servicio de backend.

Si envías tráfico desde tu red de VPC a tu servicio de GKE a través de una puerta de enlace, puedes proteger ese tráfico con los siguientes productos y funciones:

Si no usas una puerta de enlace para enviar tráfico desde tu red de VPC a tu servicio de GKE, puedes proteger ese tráfico con los siguientes productos y servicios:

Para obtener más información sobre cómo proteger GKE, consulta las prácticas recomendadas de seguridad de red y cómo comprender la seguridad de red en GKE.

Seguridad de la red del agente

Para proteger la red de un sistema de IA multiagente, debes proteger las comunicaciones a través de la red de VPC y la superficie de la API. El plano de datos de la red de VPC aborda cómo se conectan de forma segura los agentes y las herramientas. La superficie de la API define qué identidades y tipos de intercambios de datos se permiten. La aplicación de controles de acceso en capas tanto en la red de VPC como en la superficie de la API ayuda a aplicar una postura de seguridad altamente controlada y resiliente.

Cloud NGFW

El Cloud NGFW actúa como el guardián a nivel de la red para proteger las comunicaciones entre A2A y MCP. El firewall garantiza que solo el tráfico autorizado pueda llegar a los extremos del agente, ya que verifica cada conexión entrante o saliente hacia y desde otros agentes y herramientas.

Cloud NGFW es un servicio de firewall distribuido integrado en la estructura de la red de VPC. Ofrece estos niveles de funciones que operan en diferentes capas de la pila de red:

  • Cloud Next Generation Firewall Essentials: Proporciona filtrado de paquetes de firewall con estado. Las reglas de política se definen según las direcciones IP (L3), los protocolos y los puertos (L4).
  • Cloud Next Generation Firewall Standard: Proporciona la aplicación basada en IP con objetos de nombre de dominio completamente calificados (FQDN), objetos de ubicación geográfica y feeds de Google Threat Intelligence para bloquear direcciones maliciosas conocidas.
  • Cloud Next Generation Firewall Enterprise: Proporciona capacidades de inspección de aplicaciones (L7) reales con desencriptación de TLS y capacidades del sistema de detección y prevención de intrusiones (IDPS) para analizar cargas útiles en función de firmas de amenazas avanzadas.

Cloud NGFW se puede aplicar en la red de VPC para aplicar la política de firewall según las reglas necesarias para segmentar la plataforma de hosting de agentes que usaste.

  • Vertex AI Agent Engine: Los agentes que se ejecutan en Vertex AI Agent Engine se conectan a la red de VPC a través de adjuntos de red de Private Service Connect. Estos adjuntos hacen que la interfaz de red del agente aparezca dentro de una subred en la red de VPC. Las políticas de firewall de red de Cloud NGFW se aplican a la red de VPC. Las políticas filtran el tráfico según las direcciones IP de origen de la subred dedicada al adjunto de red de Private Service Connect. Para la coincidencia de tráfico, puedes usar rangos de direcciones IP de origen y de destino.
  • Cloud Run: Los servicios de Cloud Run que usan la salida de VPC directa envían tráfico directamente desde las instancias que se ejecutan dentro de una subred especificada en la red de VPC. Las políticas de firewall de red de Cloud NGFW se aplican a la subred que usa Cloud Run para filtrar el tráfico. Para la coincidencia de tráfico, puedes usar rangos de direcciones IP de origen y de destino.
  • GKE: Los clústeres de GKE nativos de VPC otorgan a los Pods direcciones IP que provienen directamente de los rangos de direcciones IP secundarias de la red de VPC. Las políticas de firewall de red pueden filtrar el tráfico según los rangos de direcciones IP de los nodos y Pods de GKE, y pueden usar etiquetas seguras y cuentas de servicio. Las etiquetas seguras se vinculan a las instancias de VM que actúan como nodos de GKE. Luego, las reglas de firewall pueden dirigir el tráfico hacia los nodos que tienen etiquetas específicas o desde ellos. Las reglas de firewall también pueden segmentar o generar tráfico desde nodos de GKE según la identidad de la cuenta de servicio asociada al grupo de nodos.

Política de salida de denegación predeterminada

Implementar una estrategia de rechazo predeterminado es una práctica recomendada de seguridad que cumple con el principio de privilegio mínimo. Esta estrategia garantiza que solo se permita el tráfico de red que se autorice de forma explícita, mientras que todo el resto del tráfico se bloquea de forma predeterminada. Esta implementación se logra estructurando las reglas de firewall con reglas ALLOW de alta prioridad para flujos conocidos y legítimos, y una regla DENY de baja prioridad que abarca todo. Todos los niveles de Cloud NGFW permiten reglas basadas en rangos de direcciones IP de origen y destino.

Las reglas de la política de firewall pueden hacer coincidir de manera eficaz el tráfico de origen de la subred de adjuntos de red de Vertex AI Agent Engine y de la subred de salida de VPC directa de Cloud Run.

A continuación, se muestra un ejemplo de una política de salida predeterminada de denegación:

  • Crea una política y reglas de firewall de red: Crea una política de firewall global o regional y asóciala a la red de VPC. Crea reglas de política de firewall que segmenten el tráfico en la dirección de salida (--direction=EGRESS) según los rangos de direcciones IP de origen (--src-ip-ranges=SRC_IP_RANGES) y los rangos de direcciones IP de destino (--dest-ip-ranges=DEST_IP_RANGES).
  • Reglas específicas de ALLOW: Usa números de prioridad más bajos, por ejemplo, del 100 al 1,000. Estas reglas permiten con precisión el tráfico de red necesario para que funcionen tus agentes de IA. Este tráfico incluye la comunicación con otros servicios internos, balanceadores de cargas, las APIs de Google requeridas o los extremos externos legítimos. Crea una regla que coincida con el tráfico de origen de la subred de adjuntos de red de Vertex AI Agent Engine o de la subred de salida de VPC directa de Cloud Run a los destinos que desees.
  • Regla general DENY: Para asegurarte de que la regla sea la última en el orden de evaluación, usa el número de prioridad más alto, por ejemplo, 2147483647. Esta regla rechaza el tráfico a cualquier destino (--dest-ip-ranges=0.0.0.0/0) que no coincida con ninguna de las reglas ALLOW anteriores.

Una política de denegación predeterminada de salida impide que los agentes de IA realicen conexiones de red que no estén autorizadas de forma explícita y bloquea la posible filtración de datos o el acceso a sitios maliciosos. La política limita los agentes alojados para que solo se comuniquen con los extremos aprobados, lo que es fundamental para mantener el control sobre las cargas de trabajo autónomas.

Consideraciones adicionales sobre las políticas de Cloud NGFW

Además de la estrategia de rechazo predeterminada que está disponible en todos los niveles de Cloud NGFW, puedes reforzar aún más la seguridad de tu red de IA multiagente con las funciones de los niveles pagados:

  • Funciones estándar de Cloud NGFW:
    • Objetos FQDN para extremos dinámicos: Los agentes de IA suelen interactuar con APIs externas, extremos de modelos o fuentes de datos cuyas direcciones IP pueden cambiar. Para acceder de forma coherente a los servicios necesarios por nombre de dominio, usa objetos FQDN en las reglas de ALLOW.
    • Controles de ubicación geográfica: Si los agentes de IA tienen requisitos de cumplimiento o no deben interactuar con servicios en regiones geográficas específicas, usa objetos de ubicación geográfica (--src-region-codes=SRC_COUNTRY_CODES) en tus reglas de firewall para restringir el tráfico hacia o desde esas ubicaciones.
    • Google Threat Intelligence: Usa Google Threat Intelligence en los filtros de salida para bloquear automáticamente la conexión de los agentes a destinos maliciosos conocidos, como servidores de comando y control (C2), anonimizadores como Tor y sitios de distribución de software malicioso. El uso de Google Threat Intelligence ayuda a contener el impacto de un agente que podría estar comprometido. Te recomendamos que incluyas estos filtros de destino en las reglas DENY con un número de prioridad más alto (orden de evaluación más bajo).
  • Funciones de Cloud NGFW Enterprise:
    • Inspección de capa 7: Para los agentes que manejan datos sensibles o que están expuestos a riesgos más altos, inspecciona las cargas útiles de los paquetes en busca de amenazas como software malicioso, software espía y exploits que no se analizan con las reglas de firewall de la capa de red.
    • Inspección de TLS: Para permitir que el motor de inspección analice el tráfico encriptado, habilita la inspección de TLS. El uso de la inspección de TLS es fundamental porque la mayoría de los ataques modernos y la comunicación de C2 están encriptados.

Para conocer otras consideraciones o limitaciones de implementación que podrían aplicarse a tu entorno, consulta estos recursos:

IAP

IAP protege las solicitudes de entrada a los clústeres de GKE proporcionando una capa central de autenticación y autorización para las apps de IA. IAP intercepta todas las solicitudes HTTPS destinadas a la puerta de enlace y verifica la identidad y los permisos del llamador. La IAP solo permite que las solicitudes autenticadas y autorizadas pasen a la carga de trabajo del servicio de backend. IAP en el balanceador de cargas de la puerta de enlace solo protege el tráfico que proviene de fuera del clúster. La comunicación dentro del clúster no pasa por IAP.

Para acceder a las apps basadas en IA alojadas en GKE y protegidas por IAP, se debe otorgar a las identidades de usuario principales el rol de IAM de Usuario de app web protegida con IAP (roles/iap.httpsResourceAccessor) en el recurso de servicio de backend protegido por IAP. Te recomendamos que configures una cuenta de servicio personalizada como la identidad de los agentes implementados. El uso de una cuenta de servicio personalizada te permite asignar permisos con mayor precisión según el principio de privilegio mínimo.

Solo otorga el rol de IAM de usuario de aplicación web protegida con IAP directamente a las cuentas de servicio de los agentes que tienen permiso para acceder a otros agentes y herramientas alojados en el recurso personalizado BackendConfig de GKE. Para permitir el acceso a las apps de Gemini Enterprise, otorga permisos vinculando el rol de IAM Cuenta de servicio de Discovery Engine (roles/discoveryengine.serviceAgent) para tu proyecto de Gemini Enterprise.

Controles del servicio de VPC

Los Controles del servicio de VPC mitigan los riesgos de robo de datos controlando estrictamente el acceso a las APIs de Google. Te recomendamos que implementes un solo perímetro macro que incluya todos los servicios compatibles. Este enfoque proporciona la defensa más sólida contra la exfiltración. Para garantizar la aplicación coherente de políticas en las arquitecturas de VPC compartida, es fundamental incluir tanto el proyecto host como todos los proyectos de servicio asociados dentro del mismo perímetro de servicio.

Para proteger la interacción entre Gemini Enterprise y Cloud Run en los límites del proyecto, ten en cuenta las siguientes recomendaciones:

  • Implementa un solo perímetro de los Controles del servicio de VPC que abarque los proyectos de Gemini Enterprise y Cloud Run.
  • Agrega todos los servicios compatibles con los Controles del servicio de VPC a la lista de servicios restringidos. Este enfoque ayuda a evitar cambios administrativos no autorizados.
  • Aplica la configuración interna de entrada y autorización para bloquear todo el acceso público a Internet a tus servicios de Cloud Run.

Los servicios de Cloud Run están protegidos por IAM. Los llamadores deben estar autenticados y tener el rol de IAM de Invocador de Cloud Run (roles/run.invoker) en el servicio de destino. El rol se verifica validando un token del encabezado de autorización. Para llamar correctamente al servicio de Cloud Run, las cuentas de servicio, como las que usa Gemini Enterprise, también deben tener el rol de invocador de Cloud Run.

Cuando Gemini Enterprise y Cloud Run se implementan en proyectos diferentes, se requiere un perímetro de Controles del servicio de VPC para configurar la entrada de Cloud Run como interna. Sin este perímetro, las llamadas entre proyectos de Gemini se tratan como tráfico externo, lo que te obliga a establecer la entrada de Cloud Run en All, lo que deja el servicio expuesto a la Internet pública.

  • La entrada de Cloud Run all se admite cuando ambas condiciones son verdaderas:
    • Los Controles del servicio de VPC no están habilitados.
    • Cloud Run y Gemini Enterprise no están en el mismo proyecto.
  • Solo se admite la entrada internal de Cloud Run para todas las demás configuraciones.

Consideraciones adicionales sobre los Controles del servicio de VPC

Cuando Cloud Run se implementa dentro de un perímetro de Controles del servicio de VPC, te recomendamos que implementes los siguientes lineamientos de políticas para garantizar una protección integral:

  • Restringe la configuración de ingreso permitida: Evita que los desarrolladores implementen accidentalmente extremos públicos estableciendo la restricción de la política de la organización run.allowedIngress. Esta restricción solo se aplica a las implementaciones nuevas. Es posible que las implementaciones anteriores no cumplan con los requisitos. Te recomendamos que audites los servicios de Cloud Run existentes dentro del perímetro y que vuelvas a implementar o actualizar los que no cumplan con la configuración de entrada y salida requerida.
    • Para permitir solo solicitudes internas, establece el valor en internal.
    • Para permitir solicitudes a través de un balanceador de cargas de aplicaciones externo, establece el valor en internal-and-cloud-load-balancing.
  • Restringe la configuración de salida de VPC permitida: Para enrutar todas las solicitudes salientes a través de la VPC de modo que las reglas de firewall perimetral puedan inspeccionarlas, establece el valor de la restricción de la política de la organización run.allowedVPCEgress en all-traffic. Este parámetro de configuración requiere que cada revisión de Cloud Run use la salida de VPC directa o un conector de Acceso a VPC sin servidores. Esta restricción solo se aplica a las implementaciones nuevas. Es posible que las implementaciones anteriores no cumplan con los requisitos. Te recomendamos que audites los servicios de Cloud Run existentes dentro del perímetro y que vuelvas a implementar o actualizar los que no cumplan con la configuración de entrada y salida requerida.
  • Coloca las imágenes y los servicios de contenedor en la misma ubicación: El repositorio de Artifact Registry que contiene tus imágenes de contenedor debe residir dentro del mismo perímetro que el servicio de Cloud Run. La extracción de imágenes entre perímetros se bloquea automáticamente, a menos que establezcas reglas explícitas de entrada y salida.
  • Administra los niveles de acceso: Las reglas de políticas de entrada de los Controles del servicio de VPC y los niveles de acceso que dependen de las identidades principales de IAM no son compatibles con las invocaciones de Cloud Run. En su lugar, debes administrar el acceso con criterios basados en la red o niveles de acceso basados en el dispositivo.

Model Armor

Model Armor es un servicio basado en APIs que proporciona mayor seguridad para las apps de IA. Los agentes de IA interactúan con Model Armor llamando para limpiar las instrucciones del usuario antes de que se envíen a un LLM y para limpiar las respuestas del modelo antes de que se devuelvan al usuario. Model Armor analiza de forma activa las instrucciones y respuestas de los LLM, lo que proporciona un punto de inspección importante para detectar riesgos emergentes y un punto de control para implementar estándares de IA responsable. Te recomendamos que uses Model Armor para garantizar el cumplimiento de los requisitos de residencia de datos y las reglamentaciones legales de soberanía de los datos. Para usar Model Armor dentro de un perímetro de Controles del servicio de VPC, debes configurar un extremo de Private Service Connect para el extremo regional de Model Armor dentro de tu red de VPC.

Model Armor es un servicio regional al que se accede de forma privada a través de extremos de Private Service Connect regionales en la red de VPC. Por ejemplo, se llama al servicio us-central1 con el extremo regional modelarmor.us-central1.rep.googleapis.com. Los extremos regionales ayudan a garantizar la residencia de datos.

Para habilitar el acceso de los agentes, configura los siguientes componentes en cada región en la que se requiera el servicio de Model Armor:

  1. Crea o identifica una subred de RFC 1918 en la región de la red de VPC en la que reside el servicio de Model Armor.
  2. Crea un endpoint regional en la subred RFC 1918.
  3. Crea una zona privada de Cloud DNS y un registro para el nombre de host del extremo regional de Model Armor (por ejemplo, modelarmor.us-central1.rep.googleapis.com) que se resuelva en la dirección IP del extremo regional.
  4. Para la interoperabilidad de Vertex AI Agent Engine, establece el intercambio de tráfico de DNS desde Vertex AI Agent Engine a la zona privada de Cloud DNS asociada con tu red de VPC. Cuando los agentes realizan solicitudes a Model Armor, Cloud DNS resuelve las solicitudes de nombre de host en la dirección IP del extremo regional de Private Service Connect en la red de VPC. Este paso no es obligatorio para los agentes alojados en Cloud Run y GKE.

Para integrar Gemini Enterprise con Model Armor, crea una plantilla de Model Armor en el mismo proyecto que Gemini Enterprise. La ubicación de la plantilla y la app de Gemini Enterprise deben ser las mismas.

Para obtener más información sobre cómo habilitar Model Armor, consulta los siguientes recursos:

Cloud Armor

Cloud Armor es un servicio de seguridad de redes distribuido que protege las apps y los servicios detrás de los balanceadores de cargas antes de que las solicitudes lleguen a los tiempos de ejecución del servicio de backend. Las cargas de trabajo de los agentes de IA implican grandes volúmenes de comunicación entre servicios que usan llamadas a A2A, MCP y APIs. La protección de Cloud Armor proporciona capas adicionales de resiliencia en el diseño de seguridad con límite de frecuencia, análisis de WAF y reglas personalizadas que se ajustan a las solicitudes agentivas esperadas. Si adjuntas políticas de seguridad de Cloud Armor a los servicios de backend del balanceador de cargas de aplicaciones, se puede filtrar el tráfico en busca de solicitudes maliciosas y aplicar límites de frecuencia, además de mitigar los ataques DSD.

Cloud Armor se puede implementar en una arquitectura de red de agentes en las siguientes situaciones:

  • Cloud Run con balanceador de cargas de aplicaciones interno: Protege los agentes y las herramientas que se ejecutan en Cloud Run con un balanceador de cargas de aplicaciones interno con backends de NEG sin servidores. Aplica políticas de seguridad de backend a la NEG sin servidores para aplicar reglas del WAF al tráfico interno y la limitación de frecuencia. Para controlar las comunicaciones del agente, puedes definir reglas personalizadas adicionales basadas en direcciones IP y encabezados.
  • Puerta de enlace: Protege los agentes y las herramientas que se ejecutan en GKE con una definición de recurso de Gateway para un balanceador de cargas de aplicaciones externo global o regional con backends de NEG zonales. Usa la API de Gateway de Kubernetes para aplicar el recurso GCPBackendPolicy con la política de seguridad de Cloud Armor definida. Si usas un balanceador de cargas de aplicaciones externo regional, Cloud Armor admite políticas de seguridad de backend con reglas del WAF, controles basados en la dirección IP y la ubicación geográfica, y límite de frecuencia. Los balanceadores de cargas de aplicaciones externos globales admiten políticas de seguridad de backend y políticas de seguridad de borde adicionales con Protección adaptable de Google Cloud Armor y Google Threat Intelligence.

Proxy web seguro

Secure Web Proxy es un servicio administrado regional que se implementa dentro de la red de VPC para filtrar el tráfico HTTP/S que se origina dentro de la red de VPC o dentro de cualquier red conectada. Actúa como un proxy centralizado y un punto de aplicación de seguridad para proporcionar control y visibilidad detallados del tráfico de Internet saliente. También actúa como un proxy explícito para las comunicaciones de servicios internos.

Secure Web Proxy admite tres modos de implementación: modo de enrutamiento de proxy explícito, modo de adjunto de servicio de Private Service Connect y modo de siguiente salto. Te recomendamos que uses Secure Web Proxy en el modo de enrutamiento de proxy explícito, que es el enfoque de este documento. En este modo, los clientes HTTP deben configurarse de forma explícita para que apunten directamente a la dirección IP o el nombre de host del Secure Web Proxy.

Para implementar el Proxy web seguro en tu red de VPC, debes configurar una subred de frontend y una subred de solo proxy. Secure Web Proxy es un servicio completamente administrado. Cuando se implementa Secure Web Proxy, se implementan y configuran automáticamente Cloud Router y Cloud NAT en tu red de VPC para una integración específica con el recurso de proxy. Esta configuración exige que todas las solicitudes salientes pasen por Secure Web Proxy antes de salir a Internet.

El uso de Secure Web Proxy como proxy explícito admite solicitudes de agentes que provienen de interfaces de Private Service Connect de Vertex AI Agent Engine, salida de VPC directa de Cloud Run y clústeres de GKE nativos de VPC. Cuando los agentes envían solicitudes a Secure Web Proxy con el método HTTP CONNECT, el tráfico de la sesión TCP se canaliza al proxy, donde se aplican las reglas de la política de seguridad. Si se permite el tráfico, Secure Web Proxy lo envía a la salida controlada de Internet o a los destinos de red privada a los que se puede enrutar el tráfico desde la red de VPC.

Enrutamiento explícito del proxy

La salida de Vertex AI Agent Engine requiere que uses una configuración de proxy explícita para que los agentes puedan llegar a destinos de Internet o rangos de direcciones IP no enrutables en la red de VPC. Para la interoperabilidad de Vertex AI Agent Engine, te recomendamos que configures el recurso de Secure Web Proxy con una dirección IP de RFC 1918 de una subred de frontend en la red de VPC. Con esta configuración, se puede acceder directamente a Secure Web Proxy desde Vertex AI Agent Engine. Luego, puede redireccionar cualquier conexión a destinos de direcciones IP no enrutables que se encuentren en la red de VPC o en redes conectadas.

Para admitir el uso de Secure Web Proxy en el modo de enrutamiento explícito por parte de la plataforma de hosting de agentes, configura estos recursos de redes:

  1. Crea o identifica una subred RFC 1918 en la red de VPC para alojar el recurso de Secure Web Proxy.
  2. Crea un registro DNS de Cloud DNS para el nombre de host de Secure Web Proxy (por ejemplo, swp.example.com) que se resuelva en la dirección IP del recurso de Secure Web Proxy.
  3. Para la interoperabilidad de Vertex AI Agent Engine, establece el intercambio de tráfico de DNS desde Vertex AI Agent Engine a la zona privada de Cloud DNS asociada con tu red de VPC. Cuando los agentes realizan solicitudes a Secure Web Proxy, Cloud DNS resuelve las solicitudes de nombre de host en la dirección IP del recurso de Secure Web Proxy en la red de VPC. Este paso no es obligatorio para los agentes alojados en Cloud Run y GKE.

Configuración de proxy del agente

La forma estándar de configurar las apps de agentes para que usen un proxy HTTP(S) es establecer estas variables de entorno:

  • HTTP_PROXY: Es la URL del servidor proxy explícito para el tráfico HTTP (por ejemplo, http://swp.example.com:8888). Esta configuración usa el método CONNECT de HTTP del cliente al proxy. Aunque se especifica HTTP, la encriptación TLS se mantiene de extremo a extremo a través del proxy, desde el tiempo de ejecución del agente hasta el extremo de destino.
  • HTTPS_PROXY: Es la URL del servidor proxy explícito para el tráfico HTTPS (por ejemplo, https://swp.example.com:8888). Al igual que el parámetro de configuración HTTP_PROXY, el parámetro de configuración HTTPS_PROXY usa TLS de forma predeterminada. Sin embargo, puedes proporcionar una capa adicional de encriptación si habilitas tu propia encriptación TLS sobre la TLS predeterminada. Para obtener más información, consulta Certificate Authority Service.
  • NO_PROXY: Es una lista separada por comas de nombres de host o direcciones IP que no deben pasar por el proxy. Por ejemplo, si agregas metadata.google.internal y 169.254.169.254 a la lista de NO_PROXY, las cargas de trabajo pueden acceder directamente al servicio de metadatos para la autenticación y autorización a las APIs y los servicios de Google.

Cuando usas el argumento env_vars para establecer variables durante la implementación, estas quedan disponibles en el entorno de ejecución del agente (por ejemplo, cuando usas os.environ en Python). La mayoría de las bibliotecas cliente HTTP estándar detectan y usan automáticamente estas variables de entorno para enrutar el tráfico a través del proxy especificado. Este enfoque es común para las apps de Python y las bibliotecas de clientes HTTP, como requests. Cuando implementes agentes, define variables de entorno para usar Secure Web Proxy en cualquier dominio privado al que deban acceder los agentes. Asegúrate de que los destinos de dominio privado también se incluyan en Cloud DNS.

En el siguiente ejemplo, se muestra la implementación de un proxy de Vertex AI Agent Engine desde un objeto de agente:

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

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

Cloud Run admite la configuración de variables de entorno a nivel de la revisión del servicio. Este enfoque anula cualquier variable de entorno con el mismo nombre que se haya establecido dentro de la imagen del contenedor. Este enfoque es útil para establecer parámetros operativos, como variables de proxy, cuando se inician las instancias del servicio.

En el siguiente ejemplo, se muestra el comando para configurar las variables de entorno cuando implementas un servicio de 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 una configuración de proxy explícita en los Pods de GKE, define un recurso ConfigMap que especifique las variables del proxy:

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

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

Para aplicar las claves de ConfigMap a los Pods, usa el campo envFrom en el manifiesto del contenedor. Esta especificación inserta las variables de entorno en el contenedor durante el tiempo de ejecución.

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

Servicio de CA

El Servicio de CA (CA Service) es obligatorio cuando el Secure Web Proxy o el Cloud NGFW se configuran para la inspección de TLS. Cuando la inspección de TLS está habilitada y el destino de una carga de trabajo usa TLS, el servicio de CA crea y firma un certificado para ese destino. Cuando el tráfico encriptado para el destino real llega a Secure Web Proxy o a Cloud NGFW, se desencripta el paquete, se inspecciona y, luego, se aplican las políticas. Si las políticas permiten el paquete, el servicio lo vuelve a encriptar para el destino final. También puedes usar el servicio de CA para proporcionar certificados a otros servicios administrados por Google.

El servicio de CA es un servicio administrado. Después de configurar CA Service, este se encarga de firmar los certificados de entidad final hasta que venza el certificado de la AC raíz. Los certificados de la CA raíz deben actualizarse para garantizar que no venzan.

El servicio de CA admite estas capacidades para habilitar la inspección del tráfico y la administración de certificados a gran escala en una arquitectura de IA con varios agentes:

  • Inspección de TLS: Se requiere el uso de una CA privada para realizar una inspección de TLS completa. Para desencriptar y analizar por completo las cargas útiles de HTTPS, el dispositivo proxy intermedio (Secure Web Proxy o Cloud NGFW) debe finalizar la sesión de TLS con el cliente. El proxy debe presentar un certificado válido que el cliente acepte como de confianza para el dominio solicitado.

    El servicio de CA puede generar y firmar de forma dinámica un certificado de suplantación específico del sitio solicitado. Cuando el cliente tiene instalado el certificado raíz de la AC privada en su almacén de confianza, acepta este certificado creado de forma dinámica como válido. El cliente confía en el certificado que envía el proxy, por lo que envía la solicitud. El proxy finaliza la sesión de TLS, desencripta el paquete, inspecciona el contenido y, luego, aplica las políticas.

  • Distribución de certificados: Los recursos de clientes internos, como los agentes de IA que se ejecutan en Vertex AI Agent Engine, Cloud Run o GKE, necesitan que se agregue el certificado de la AC raíz privada a sus almacenes de confianza locales. Al almacenar la clave pública del certificado de la AC raíz en Secret Manager, los agentes de IA pueden extraer el certificado durante el inicio y agregarlo a su almacén de confianza del sistema.

    Los recursos del servidor interno, como los balanceadores de cargas de aplicaciones internos, necesitan certificados emitidos por la CA privada para actuar como extremos de servidor de confianza y finalizar las sesiones de TLS del cliente. Los balanceadores de cargas de aplicaciones se integran con las configuraciones de emisión del Administrador de certificados para automatizar la firma de la solicitud de certificado por parte del servicio de CA y su implementación en el balanceador de cargas.

Para obtener más información sobre las operaciones de certificados, consulta estos recursos:

Seguridad de la conexión A2A

Los agentes raíz se comunican con una gran variedad de subagentes y servidores de MCP que se implementan en varias plataformas de alojamiento de tiempo de ejecución. Cada entorno introduce requisitos únicos de redes y seguridad que deben abstraerse en la capa de A2A o MCP.

En el siguiente diagrama, se muestran los componentes y las posibles rutas de conexión que admite esta guía de diseño:

Patrones de conectividad de Agent2Agent (A2A) entre diferentes plataformas de alojamiento, como GKE, Cloud Run y Vertex AI Agent Engine, y conexiones a servidores de MCP y a Internet.

En el diagrama anterior, se resumen estas posibilidades de conexión:

  • Los usuarios interactúan con el sistema basado en agentes a través de una app de Gemini Enterprise.
  • La app de Gemini Enterprise usa la infraestructura de Google para conectarse a un agente raíz que se ejecuta en GKE, Cloud Run o Vertex AI Agent Engine.
  • La app de Gemini Enterprise y los agentes raíz usan la infraestructura de Google para conectarse a Model Armor y al LLM de Gemini en Vertex AI.
  • Los agentes raíz pueden usar la infraestructura de Google para conectarse a subagentes que se ejecutan en Cloud Run o Vertex AI Agent Engine.
  • Los agentes raíz pueden usar direcciones IP privadas para conectarse a subagentes que se ejecutan en Vertex AI Agent Engine, Cloud Run y GKE. Estas conexiones deben enrutarse a través de una red de VPC.
  • Tanto los agentes raíz como los subagentes pueden conectarse a servidores de MCP que se ejecutan en Cloud Run o GKE. Los agentes que se conectan a los servidores de MCP pueden usar la infraestructura de Google o una red de VPC. Los servidores de MCP proporcionan acceso a herramientas alojadas enGoogle Cloud, de forma local, en otra nube o en Internet.
  • Se puede acceder directamente a los servicios alojados en Internet a través de Secure Web Proxy.

En las siguientes secciones, se proporcionan recursos para las rutas de datos de tiempo de ejecución y los controles de seguridad que se requieren para las interacciones seguras de A2A. Esta información sirve como estándar arquitectónico para establecer la conectividad privada y, también, para implementar las defensas de múltiples capas que son necesarias para proteger la ruta de datos de extremo a extremo entre los agentes.

Agente de origen de GKE

En la siguiente tabla, se proporcionan recursos para ayudarte a proteger el tráfico cuando GKE es el agente de origen. Este tráfico viaja a través de la red de VPC que aloja el clúster de GKE.

Agente de destino (ruta de datos) Control de seguridad
Vertex AI Agent Engine (interno)
Cloud Run (interno)
Cloud Run (Private Service Connect para las APIs de Google)
Acceso a Cloud Run (NEG sin servidores)
GKE
Internet a través de la red de VPC

Agente fuente interno de Vertex AI Agent Engine

En la siguiente tabla, se proporcionan recursos para ayudarte a proteger el tráfico cuando Vertex AI Agent Engine es el agente de origen y el tráfico viaja directamente a través de la infraestructura de Google. En estas rutas, no se involucra ninguna red de VPC.

Agente de destino (ruta de datos) Control de seguridad
Vertex AI Agent Engine (interno)
Cloud Run (interno)

Agente fuente de Vertex AI Agent Engine (interfaz de Private Service Connect)

En la siguiente tabla, se proporcionan recursos para ayudarte a proteger el tráfico cuando Vertex AI Agent Engine es el agente de origen y el tráfico usa una interfaz de Private Service Connect para viajar a través de una red de VPC.

Agente de destino (ruta de datos) Control de seguridad
Cloud Run (Private Service Connect, APIs de Google)
Acceso a Cloud Run (NEG sin servidores)
GKE
Internet a través de la red de VPC

Agente de origen interno de Cloud Run

En la siguiente tabla, se proporcionan recursos para ayudarte a proteger el tráfico cuando Cloud Run es el agente de origen y el tráfico viaja directamente a través de la infraestructura de Google. En estas rutas, no se involucra ninguna red de VPC.

Agente de destino (ruta de datos) Control de seguridad
Vertex AI Agent Engine (interno)
Cloud Run (interno)

Agente de origen de Cloud Run (salida de VPC directa)

En la siguiente tabla, se proporcionan recursos para ayudarte a proteger el tráfico cuando Cloud Run es el agente de origen y el tráfico usa la salida directa de VPC para viajar a través de una red de VPC.

Agente de destino (ruta de datos) Control de seguridad
Cloud Run (Private Service Connect para las APIs de Google)
Acceso a Cloud Run (NEG sin servidores)
GKE
Internet a través de la red de VPC
Private Service Connect de Vertex AI Agent Engine para las APIs de Google

Seguridad de la conexión de MCP

En la siguiente lista, se describen las plataformas de hosting y los controles de defensa en profundidad que participan en la protección de la ruta de datos entre los tiempos de ejecución del agente y los servidores de MCP. Para los agentes fuente en Vertex AI Agent Engine, en Cloud Run o en GKE, usa los siguientes controles de seguridad según el servidor de MCP de destino:

  • Internet:
    • Controles del servicio de VPC
    • Model Armor
    • Cloud NGFW
    • Proxy web seguro
  • Google MCP:
    • Controles del servicio de VPC
    • Model Armor

¿Qué sigue?

Colaboradores

Autores:

  • Deepak Michael | Ingeniero de Atención al cliente especializado en herramientas de redes
  • Michael Larson | Ingeniero de Atención al cliente y especialista en redes
  • Victor Moreno | Gerente de producto, Herramientas de redes de Cloud

Otros colaboradores: