Patrones de redes privadas de varios agentes en Google Cloud

Last reviewed 2026-11-09 UTC

En este documento, se proporcionan lineamientos para ayudarte a diseñar una infraestructura de red privada que admita una app de Gemini Enterprise de varios agentes de acceso público con conexiones privadas entre agentes, subagentes y herramientas. El diseño de red proporciona conexiones privadas para los agentes que se alojan en Agent Runtime en Gemini Enterprise Agent Platform, 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 de propiedad de la organización. Las redes privadas te permiten evitar exponer este tráfico al Internet público. Este diseño usa la infraestructura de red de Google Cloud , los recursos de red de nube privada virtual (VPC) y la 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 enrutándolas a través de una red de VPC. Para mover 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 de VPC directa de Cloud Run. Cloud Next Generation Firewall (Cloud NGFW) controla el tráfico que pasa por la red de VPC. Las capas de seguridad adicionales proporcionan una salida de Internet controlada con Secure Web Proxy y proporcionan políticas de acceso al servicio de la API con 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 infraestructura y apps de IA en la nube. En este documento, se supone que tienes conocimientos básicos de los agentes y modelos de IA, y que conoces los conceptos de redes de Google Cloud .

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 agentes secundarios alojados en Google 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 Runtime, 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 de los agentes personalizados. Los agentes raíz personalizados se registran en Gemini Enterprise y se ponen a disposición de los usuarios finales en las apps. El agente raíz personalizado actúa como un organizador de flujos de trabajo de nivel superior y delega tareas especializadas a los agentes secundarios. Esta arquitectura usa agentes raíz personalizados que se alojan en Agent Runtime, Cloud Run o GKE.
  2. Agentes raíz que interactúan con agentes secundarios y herramientas. El núcleo del flujo de trabajo del sistema de IA y la lógica empresarial residen en el agente raíz y en los agentes secundarios especializados. La flexibilidad en el framework del agente, el entorno de ejecución y la plataforma de hosting 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 red privadas que definas y que expongan otros extremos privados, controles de seguridad empresarial y una accesibilidad de la red más amplia.

Descripción general de alto nivel de una arquitectura de red multiagente.

La arquitectura incluye los siguientes componentes:

  • App de Gemini Enterprise: Es la interfaz de usuario para que los usuarios accedan a una interfaz de chat integrada en la app y, así, interactuar con el sistema de IA multiagente. Los usuarios pueden acceder a las apps de Gemini Enterprise a través de la Internet pública o de forma privada a través de conexiones híbridas.
  • Agentes personalizados: Son agentes raíz que se crean y registran con Gemini Enterprise y que se alojan en Agent Runtime, Cloud Run o GKE. Estos agentes raíz funcionan como organizadores que delegan tareas a los agentes secundarios.
  • Red de VPC: Es un recurso que controlas para proporcionarles a los agentes conectividad de red IP a extremos privados y una mayor accesibilidad de red. La red de VPC proporciona una plataforma para implementar controles de seguridad de redes y conectividad privada para las solicitudes de agentes a otros agentes y herramientas.
  • Agentes secundarios: Son agentes especializados que se activan con el flujo de trabajo del agente raíz. Los agentes secundarios se comunican con el protocolo A2A, que permite la interoperabilidad entre agentes, independientemente del lenguaje de programación y el entorno 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 ellas usando la especificación del MCP.

Este patrón de diseño de alto nivel de varios agentes destaca los componentes de red que se encuentran en un sistema de IA de varios agentes. 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 agéntica.

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 red y seguridad.

En una arquitectura de VPC compartida, un proyecto host contiene los recursos de red compartidos, incluidas las redes de VPC, Cloud Routers, subredes, firewalls y Cloud DNS. Los administradores pueden otorgar acceso a los proyectos de servicio para que usen estos recursos. Los proyectos de servicio contienen los recursos del entorno de ejecución de agentes, incluidos Agent Runtime, Cloud Run, GKE, Gemini Enterprise y los 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 de IA:

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

Cuando centralizas las implementaciones de red y seguridad dentro de un proyecto host, creas un único punto de administración para la comunicación de agente a agente y de agente a servicio. Este diseño simplifica la aplicación de políticas de seguridad en muchos proyectos de servicio diferentes y, al mismo tiempo, garantiza una conectividad coherente.

Puedes incorporar tu red de VPC compartida en una Red Multinube con los 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 completa a las rutas del concentrador de NCC y conectividad a los puntos de acceso de servicio 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 lo siguiente:

  • Otras redes de VPC a través del intercambio de tráfico entre redes de VPC, dispositivos multi-NIC o NCC.
  • Extremos de Private Service Connect para acceder a los servicios del productor.
  • Servicios administrados que tienen direcciones IP privadas, como Cloud SQL
  • Frontends del balanceador de cargas interno y 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 multinube 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 de IA, herramientas y servicios de asistencia.

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

Herramientas de redes 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 las herramientas de redes entre el usuario y la app de Gemini Enterprise, y se describen las herramientas de redes entre la app y los agentes.

Chat de usuario 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 de los usuarios, puedes configurar las URLs de la API 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 Configura el acceso privado a la IU.

Apps de Gemini Enterprise para 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 Agent Runtime o la URL del agente 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 en Gemini Enterprise, puedes implementarlo en cualquier lugar como un agente personalizado. Los agentes personalizados en Agent Runtime y en Cloud Run pueden usar rutas de red privada existentes sin configurar recursos de red 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 Herramientas de 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 Gemini Enterprise Agent Platform. La ruta de red y los mecanismos de autorización varían según la plataforma de hosting que uses:

  • Agentes personalizados en Agent Runtime: El agente de servicio de Discovery Engine de Agent Platform incluye los roles de Identity and Access Management (IAM) de Agent Platform necesarios para invocar recursos de Agent Runtime como una función integrada. El sistema enruta las solicitudes que se realizan al servicio de la API de Agent Platform 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 Discovery Engine de Agent Platform para realizar llamadas a la URL predeterminada de .run.app que se registra desde la tarjeta del agente, adjuntando el token de ID de OIDC del agente de servicio en el encabezado de autenticación de X-Serverless-Authorization. Para que el servicio de Cloud Run del agente de IA autorice estas llamadas, debes otorgar el rol de IAM de invocador de Cloud Run (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 a la entrada de Google Front End (GFE) para Cloud Run.

  • Agentes personalizados en GKE: Las apps de Gemini Enterprise usan la identidad del agente de servicio de Agent Platform Discovery Engine para realizar llamadas a la URL que se registra desde la tarjeta del agente. El DNS público debe poder resolver el nombre de host en una dirección IP externa administrada por 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, recomendamos que Gemini Enterprise llame a un agente A2A alojado en GKE con Identity-Aware Proxy (IAP). Para que IAP autorice estas llamadas, debes otorgar el rol de IAM de usuario de app web protegida por IAP (roles/iap.httpsResourceAccessor) al agente de servicio de Discovery Engine. La red de producción de Google enruta las solicitudes a GKE al GFE para la entrada del balanceador de cargas de aplicaciones externo.

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

Herramientas de redes privadas para plataformas de hosting de agentes

Después de que un usuario inicia una solicitud a la app de Gemini Enterprise, se inician solicitudes desde los agentes raíz personalizados a los subagentes y las herramientas. Las plataformas de hosting de agentes personalizados proporcionan la interfaz entre Gemini Enterprise y tus redes de VPC. Las plataformas de hosting para tus agentes y herramientas alojados en contenedores son Agent Runtime, 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 agéntica.

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

  • Agentes personalizados en Agent Runtime: Las interfaces de Private Service Connect conectan los entornos de ejecución de Agent Runtime con la red de VPC. Creas un adjunto de red en una subred de tu red de VPC y le otorgas permiso de tiempo de ejecución a Agent Runtime para conectarse a ella. El tráfico que se envía desde Agent Runtime aparece en la red de VPC como si se originara en la dirección IP de la subred del adjunto. 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 VPC compartida. El tráfico que se envía desde Cloud Run aparece en la red de VPC como si se originara 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 la 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. Todo el tráfico de salida de GKE se enruta a través de la red de VPC.

En las siguientes secciones, se proporcionan instrucciones adicionales para administrar las solicitudes de entrada y salida de la red de VPC para cada plataforma de hosting de agentes. Las consideraciones de red se aplican a las funciones de agente raíz y subagente.

Herramientas de redes de Agent Runtime

En esta sección, se describen las redes privadas para los agentes raíz y los agentes secundarios que se alojan en Agent Runtime. Si usas Agent Runtime para alojar tu agente raíz, debes implementar Gemini Enterprise y Agent Runtime en el mismo proyecto.

Agent Runtime aloja contenedores en la infraestructura de Google fuera de tu red de VPC. Para habilitar la conectividad privada con 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 las dos conexiones anteriores.

Salida de Agent Runtime a la red de VPC

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

Para conectar agentes a recursos que están dentro de tu red de VPC, Agent Runtime usa interfaces de Private Service Connect. Agent Runtime implementa una interfaz de red en el proyecto de usuario que se conecta a un recurso de adjunto de red en tu proyecto. Esta conexión crea una ruta de datos segura entre el entorno de ejecución de Agent Runtime y la red de VPC. Cuando configuras una interfaz de Private Service Connect en tu proyecto de Agent Runtime, 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 la salida de la red de VPC de Agent Runtime, consulta estos recursos:

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

Entrada de Agent Runtime desde la red de VPC

Las solicitudes a los agentes que se ejecutan en Agent Runtime se realizan con el extremo de API de Agent Platform (aiplatform.googleapis.com). Para llegar a los extremos de la API de Google con rutas de red privadas desde la red de VPC, usa el Acceso privado a Google o 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 Agent Platform 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 googleapis.com resuelve las solicitudes de la API de Agent Platform. 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 de tu red de VPC a Agent Runtime con los siguientes productos y funciones:

Consideraciones adicionales sobre la red de Agent Runtime

La salida de Agent Runtime que usa interfaces de Private Service Connect solo puede enrutar a rangos de direcciones IP RFC 1918 en la red de VPC. Para conocer los rangos de destino específicos que no se pueden enrutar con la salida de Agent Runtime, consulta Requisitos de rango de IP de subred. Para llegar a destinos de rango 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 Agent Runtime 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 Agent Runtime se implementa con una interfaz de Private Service Connect, la salida de Internet directa se inhabilita, independientemente de los Controles del servicio de VPC. Si necesitas que tu agente acceda a un destino al que Agent Runtime no puede llegar normalmente, como Internet, haz lo siguiente:

  1. Configura Secure Web Proxy en una subred 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 Agent Runtime 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 especificando el nombre de host y el puerto de Secure Web Proxy.
    2. Si accedes a un destino privado, configura una zona del DNS privado para ese destino.

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

Herramientas de redes de Cloud Run

En esta sección, se describen las redes privadas para los agentes raíz y los subagentes que se alojan 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 las dos conexiones anteriores.

Salida de Cloud Run a la red de VPC

Para iniciar conexiones de Cloud Run a 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 de 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 que están asociadas con la red de VPC. No se requiere ninguna configuración adicional de 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 la 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 estable de *.run.app para los servicios de Cloud Run que ejecutan cargas de trabajo de agentes o herramientas de IA. Estos extremos se entregan con el mismo punto de entrada de GFE que entrega 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 URL run.app resuelve las solicitudes de los servicios de Cloud Run. La red de VPC enruta la solicitud directamente a través de la red de producción de Google.

Establecer la entrada de Cloud Run en Interna restringe el acceso a tu servicio, ya que solo permite solicitudes de fuentes internas verificadas. Entre las fuentes aprobadas, se incluyen las siguientes:

  • Redes de VPC del proyecto de servicio de Cloud Run.
  • La red de VPC compartida que aloja el extremo de salida de VPC directa.
  • Recursos que se encuentran dentro del mismo perímetro de los 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 que llaman y los que se llaman, el tráfico que proviene de fuera del proyecto de servicio de Cloud Run o del entorno de VPC compartida se trata como externo. Este tráfico incluye el tráfico de otros servicios de Google Cloud, como Agent Runtime y otros servicios de Cloud Run. Para satisfacer la verificación de entrada interna de Cloud Run, este tráfico se debe enrutar de manera que parezca que se origina en la red de VPC del servicio de destino.

Para proporcionar la atribución de red interna necesaria, puedes realizar una de las siguientes acciones:

  • Usa extremos de Private Service Connect para permitir que los servicios de otras VPC o proyectos 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 frente a 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 las 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 al principal 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 estos recursos:

Si usas el Acceso privado a Google o los extremos de Private Service Connect para las APIs de Google con el objetivo de 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 herramientas de redes para los agentes que se basan en GKE.

GKE y Gemini Enterprise

Como host para agentes y herramientas de IA, GKE ofrece una plataforma altamente personalizable para los controles de red y seguridad. Un sistema de IA de agentes múltiples que se implementa en GKE puede proporcionar eficiencia operativa a gran escala. Se puede integrar de forma estrecha 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 habilitar 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 hasta 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 de defensa en profundidad integral que proteja a 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, incluidos el plano de control, el aprovisionamiento de nodos, el endurecimiento de la seguridad y el escalamiento.
  • Estándar: Google administra el plano de control. Conservas toda la responsabilidad de las configuraciones de los grupos de nodos, como seleccionar los tipos de máquinas, administrar las imágenes de SO y realizar el escalado manual.
Endurecimiento de la infraestructura y del plano de control
  • Clústeres de GKE privados: Aprovisiona 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: Restringe el acceso de administrador 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 la IAM y los Controles del servicio de VPC de Google Cloud.
Identidad y acceso (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 su contexto de dispositivo.
Protección perimetral y administración del tráfico
  • Cloud Armor: Proporciona una seguridad perimetral sólida, incluidas las reglas de firewall de aplicación web (WAF) para ayudar a bloquear cargas útiles maliciosas, protección contra DSD para ayudar a garantizar el tiempo de actividad y límite de frecuencia para ayudar a evitar el agotamiento del servicio.
  • Model Armor: Diseñado específicamente para la seguridad de los LLM, Model Armor inspecciona y limpia las instrucciones y respuestas en tiempo real para evitar la inyección de instrucciones y el robo de datos.
Aislamiento de red interna
  • Políticas de red de Kubernetes: Aplica la comunicación detallada y 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 enruta las conexiones salientes de los agentes que se alojan 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 de Pods se reservan especificando el rango de IP de Pods.
  • 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 está en un nodo diferente dentro del clúster, el tráfico se enruta con la tabla de enrutamiento de la red de VPC. Para que un Pod de agente se comunique con otros recursos de VPC, como balanceadores de cargas o extremos de Private Service Connect, puede llegar al destino con el mismo enrutamiento de VPC estándar, sujeto a las reglas de firewall.

Puedes ayudar a 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 objetos Service de Kubernetes proporcionan acceso a los recursos de GKE. Para un sistema de IA de 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 y, además, integraciones de seguridad. Sin embargo, hay otras opciones de servicio de Ingress 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 que se alojan 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 la puerta de enlace. Proporciona análisis de WAF, filtrado basado en dirección IP y ubicación geográfica, protección DSD y limitación de frecuencia antes de que el tráfico llegue al clúster de GKE o a 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 emisores 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 ayudar a 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 Prácticas recomendadas para la seguridad de redes y Comprende la seguridad de redes 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 plataforma de la API define qué identidades y tipos de intercambios de datos se permiten. La aplicación de controles de acceso en capas en la red de VPC y la superficie de la API ayuda a aplicar una postura de seguridad altamente controlada y resiliente.

Cloud NGFW

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

Cloud NGFW es un servicio de firewall distribuido que está 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 aplicación de políticas basada en IP con objetos de nombre de dominio completamente calificado (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 apps (L7) reales con desencriptación de TLS y capacidades de sistema de detección y prevención de intrusiones (IDPS) para analizar las cargas útiles en busca 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 que se necesitan para orientar la plataforma de hosting del agente que usaste.

  • Agent Runtime: Los agentes que se ejecutan en Agent Runtime se conectan a la red de VPC con 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 que se especifica 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 la VPC asignan a los Pods direcciones IP que provienen directamente de los rangos de direcciones IP secundarios de la red de VPC. Las políticas de firewall de red pueden filtrar el tráfico en función de los rangos de direcciones IP para los nodos y Pods de GKE, y las políticas 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 orientar o generar tráfico desde nodos que tienen etiquetas específicas. Las reglas de firewall también pueden orientar o generar tráfico desde los nodos de GKE según la identidad de la cuenta de servicio asociada con el grupo de nodos.

Política de denegación de salida predeterminada

Implementar una estrategia de denegación predeterminada 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 autoriza 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 los flujos legítimos conocidos y una regla DENY general de baja prioridad. 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 coincidir de forma eficaz con el tráfico de origen de la subred del adjunto de red de Agent Runtime 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 de denegación predeterminada:

  • 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 se orienten al 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, APIs de Google requeridas o extremos externos legítimos. Crea una regla que coincida con el tráfico de origen de la subred de adjunto de red de Agent Runtime o de la subred de salida de VPC directa de Cloud Run a los destinos que desees.
  • Regla general de 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 de salida predeterminada evita que los agentes de IA realicen conexiones de red que no estén autorizadas de forma explícita y bloquea el posible robo de datos o el acceso a sitios maliciosos. La política limita los agentes alojados para que solo se comuniquen con 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

Más allá de la estrategia de rechazo predeterminada que está disponible con todos los niveles de Cloud NGFW, puedes fortalecer aún más la seguridad de redes de IA de varios agentes con las funciones del nivel pagado:

  • Funciones de Cloud NGFW Standard:
    • Objetos de 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 obtener acceso 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 que los agentes se conecten a destinos maliciosos conocidos, como servidores de comando y control (C2), anonimizadores como Tor y sitios de distribución de malware. El uso de Google Threat Intelligence ayuda a contener el impacto de un agente potencialmente 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: En el caso de 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 malware, 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, ya que 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 emisor. 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 Gateway 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 de 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 con 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 la app web protegida con IAP directamente a las cuentas de servicio de los agentes que tienen permitido acceder a otros agentes y herramientas que se alojan en el servicio de GKE al que se orienta el recurso personalizado GCPBackendPolicy (o BackendConfig para Ingress). Para permitir el acceso a las apps de Gemini Enterprise, otorga permisos vinculando el rol de IAM de 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 de forma estricta el acceso a las APIs de Google. Te recomendamos que implementes un solo macroperímetro que incluya todos los servicios compatibles. Este enfoque proporciona la defensa más sólida contra el robo de datos. Para garantizar la aplicación coherente de políticas en las arquitecturas de VPC compartida, es fundamental incluir el proyecto host y todos los proyectos de servicio asociados dentro del mismo perímetro de servicio.

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

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

Los servicios de Cloud Run están protegidos por IAM. Los emisores deben autenticarse 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 Authorization (o el encabezado X-Serverless-Authorization cuando Gemini Enterprise llama a una URL predeterminada de .run.app). Para llamar correctamente al servicio de Cloud Run, las cuentas de servicio, como las que usa Gemini Enterprise, también deben tener asignado 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 Enterprise se tratan como tráfico externo, lo que te obliga a configurar la entrada de Cloud Run como Todo, lo que deja el servicio expuesto a la Internet pública.

  • La entrada de Cloud Run all se admite cuando se cumplen las siguientes condiciones true:
    • 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 de Cloud Run internal 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 las siguientes protecciones de políticas para ayudar a garantizar una protección integral:

  • Restringe la configuración de entrada permitida: Evita que los desarrolladores implementen de forma accidental 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 perimetrales 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 actualices los que no cumplan con la configuración de entrada y salida requerida.
  • Coloca imágenes de contenedor y servicios: 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 de entrada y salida explícitas.
  • Administra los niveles de acceso: Las reglas de la política de entrada de los Controles del servicio de VPC y los niveles de acceso que dependen de las identidades de las 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 seguridad mejorada para las apps de IA. Los agentes de IA interactúan con Model Armor realizando llamadas para limpiar las instrucciones de los usuarios 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 los datos y de 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 los 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 RFC 1918 en la región de la red de VPC en la que reside el servicio de Model Armor.
  2. Crea un extremo 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 Agent Runtime, establece el intercambio de tráfico de DNS desde Agent Runtime hasta la zona privada de Cloud DNS que está asociada a 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 que se alojan 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 debe ser la misma.

Para obtener más información sobre cómo habilitar Model Armor, consulta estos 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 entornos 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 la API, A2A y MCP. 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 de agentes 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 para detectar solicitudes maliciosas y controlarlo con límites de frecuencia, y se pueden 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 al NEG sin servidores para aplicar reglas de WAF al tráfico interno y limitar la frecuencia. Para controlar las comunicaciones de los agentes, 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 puerta de enlace 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 de WAF, direcciones IP y controles basados en 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 perimetral adicionales con Google Cloud Armor Adaptive Protection y Google Threat Intelligence.

Secure Web Proxy

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 medidas 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 internas del servicio.

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 próximo 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 al nombre de host de Secure Web Proxy.

Para implementar Secure Web Proxy 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 la 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 Agent Runtime, salida de VPC directa de Cloud Run y clústeres de GKE nativos de la VPC. Cuando los agentes envían solicitudes al Secure Web Proxy con el método HTTP CONNECT, el tráfico de la sesión de TCP se canaliza al proxy en el que 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 de Internet controlada o a los destinos de red privada que se pueden enrutar por la red de VPC.

Enrutamiento de proxy explícito

La salida de Agent Runtime requiere que uses una configuración de proxy explícita para que los agentes lleguen a destinos de Internet o rangos de direcciones IP no enrutables en la red de VPC. Para la interoperabilidad de Agent Runtime, 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 Agent Runtime. Luego, puede actuar como proxy para 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 red:

  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 Agent Runtime, establece el intercambio de tráfico de DNS desde Agent Runtime hasta la zona privada de Cloud DNS que está asociada a tu red de VPC. Cuando los agentes realizan solicitudes al proxy web seguro, Cloud DNS resuelve las solicitudes de nombre de host en la dirección IP del recurso del proxy web seguro en la red de VPC. Este paso no es obligatorio para los agentes que se alojan 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 HTTP CONNECT 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 Agent Runtime 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 habilitando 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 NO_PROXY, las cargas de trabajo pueden acceder directamente al servicio de metadatos para la autenticación y autorización en las APIs y los servicios de Google.

Cuando usas el argumento env_vars para establecer variables durante la implementación, estas pasan a estar 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 descubren 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 cliente 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 una implementación de proxy de Agent Runtime desde un objeto de agente:

import agentplatform

client = agentplatform.Client(
    project="PROJECT_ID",
    location="LOCATION",
)

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

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

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 en la imagen de 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 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 las claves ConfigMap a los Pods, usa el campo envFrom en el manifiesto del contenedor. Esta especificación inserta las variables de entorno en el contenedor en el entorno 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 AC es obligatorio cuando se configura Secure Web Proxy o Cloud NGFW para la inspección de TLS. Cuando la inspección de TLS está habilitada y el destino de una carga de trabajo usa TLS, CA Service 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 AC es un servicio administrado. Después de configurar CA Service, este controla la firma de certificados de hoja hasta que venza el certificado de la AC raíz. Los certificados de la AC raíz se deben actualizar para garantizar que no venzan.

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

  • Inspección de TLS: Se requiere el uso de una CA privada para la inspección de TLS completa. Para desencriptar y analizar por completo las cargas útiles de HTTPS, el dispositivo proxy intermediario (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 confiable para el dominio solicitado.

    El servicio de CA puede generar y firmar de forma dinámica un certificado de suplantación de identidad específico del sitio para el sitio que se solicita. Cuando el cliente tiene el certificado de la AC raíz privada instalado 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 Agent Runtime, Cloud Run o GKE, necesitan que se agregue el certificado de la AC raíz privada a sus almacenes de confianza locales. Si almacenas 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 internos del servidor, 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 de los clientes. Los balanceadores de cargas de aplicaciones se integran en las configuraciones de emisión del Administrador de certificados para automatizar el servicio de CA que firma la solicitud de certificado y lo implementa en el balanceador de cargas.

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

Seguridad de la conexión de A2A

Los agentes raíz se comunican con un conjunto diverso de agentes secundarios y servidores de MCP que se implementan en varias plataformas de hosting de entornos de ejecución. Cada entorno introduce requisitos de seguridad y redes únicos que debe abstraer 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 hosting, incluidas GKE, Cloud Run y Agent Runtime, 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 de 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 Agent Runtime.
  • 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 Agent Platform.
  • Los agentes raíz pueden usar la infraestructura de Google para conectarse a los agentes secundarios que se ejecutan en Cloud Run o Agent Runtime.
  • Los agentes raíz pueden usar direcciones IP privadas para conectarse a los agentes secundarios que se ejecutan en Agent Runtime, 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 en Google 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 acceso de datos del entorno de ejecución y los controles de seguridad que se requieren para las interacciones seguras de A2A. Esta información sirve como estándar de arquitectura para establecer la conectividad privada y para implementar las defensas de varias 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 acceso de datos) Control de seguridad
Agent Runtime (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 de origen de Agent Runtime (interno)

En la siguiente tabla, se proporcionan recursos para ayudarte a proteger el tráfico cuando Agent Runtime es el agente de origen y el tráfico viaja directamente por la infraestructura de Google. En estas rutas, no participa ninguna red de VPC.

Agente de destino (ruta de acceso de datos) Control de seguridad
Agent Runtime (interno)
Cloud Run (interno)

Agente de origen de Agent Runtime (interfaz de Private Service Connect)

En la siguiente tabla, se proporcionan recursos para ayudarte a proteger el tráfico cuando Agent Runtime 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 acceso 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

Agente de origen de Cloud Run (interno)

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 por la infraestructura de Google. En estas rutas, no hay ninguna red de VPC involucrada.

Agente de destino (ruta de acceso de datos) Control de seguridad
Agent Runtime (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 de VPC directa para viajar a través de una red de VPC.

Agente de destino (ruta de acceso 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
Agent Runtime (Private Service Connect 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 acceso de los datos entre los entornos de ejecución de agentes y los servidores de MCP. Para los agentes de origen en Agent Runtime, 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
    • Secure Web Proxy
  • MCP de Google:
    • 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, especialista en herramientas de redes
  • Victor Moreno | Gerente de producto, Herramientas de redes de Cloud

Otros colaboradores: