Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Configura Agent Gateway con conectividad de VPC

En este documento, se explica el proceso de configuración de la conectividad de VPC cuando se implementa una Agent Gateway para que pueda comunicarse de forma privada con una red de VPC de tu organización.

Configurar la conectividad de VPC te permite hacer lo siguiente:

Aplicar la salida de VPC para el tráfico: Enruta el tráfico que se origina en tus agentes a través del adjunto de red de Private Service Connect a tu red de VPC con el modo PRIVATE_RANGES_ONLY o ALL_TRAFFIC.
Rango de direcciones IP de origen estático: El tráfico de salida usa el rango de direcciones IP privadas de la subred de adjunto de red de Private Service Connect como su dirección IP de origen. Este rango de IP de origen estático te permite configurar políticas de firewall para tu red de VPC con el objetivo de controlar el tráfico que proviene de la puerta de enlace.
Resolución de DNS personalizada: Resuelve nombres de dominio privados internos y nombres de dominio externos directamente desde tus agentes con el intercambio de tráfico de Cloud DNS.
Seguridad perimetral: Protege las comunicaciones de los agentes con los perímetros de servicio de los Controles del servicio de VPC.
Validación de certificados privados o autofirmados: Conéctate a destinos que usen AC privadas o certificados autofirmados.

Para configurar la conectividad de VPC, crea una plantilla de conectividad de Agent Gateway (AgentConnectivityTemplate) en la que definas y administres la configuración de red de salida para tus instancias de Agent Gateway.

Cómo funciona la conectividad de VPC

Cuando implementas un Agent Gateway con una plantilla de conectividad, la puerta de enlace usa una interfaz de Private Service Connect para enrutar el tráfico saliente del agente a la red de VPC designada.

Modos de salida de VPC

Configura cómo la puerta de enlace enruta el tráfico a través del adjunto de red con el parámetro de configuración vpcEgress en la plantilla de conectividad.

Tráfico a rangos de direcciones IP privadas (PRIVATE_RANGES_ONLY): Enruta el tráfico destinado solo a rangos de direcciones IP privadas a tu red de VPC. El tráfico saliente se enruta a tu red de VPC solo si la dirección IP de destino se encuentra en uno de los siguientes rangos:
- RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
- RFC 6598: 100.64.0.0/10
- Clase E: 240.0.0.0/4
- private.googleapis.com: 199.36.153.8/30
- restricted.googleapis.com: 199.36.153.4/30
- Extremos de PSC para las APIs de Google: Si implementas un extremo de Private Service Connect personalizado para las APIs de Google con una dirección IP privada interna en tu red de VPC, el tráfico a este extremo se enruta a través de tu red de VPC. Asegúrate de que el intercambio de tráfico de Cloud DNS esté configurado en la plantilla de conectividad para que Agent Gateway resuelva correctamente los dominios de la API de Google en la dirección IP de tu extremo de PSC interno.
Las solicitudes a las APIs de Google públicas estándar se controlan automáticamente con el Acceso privado a Google, y el tráfico vinculado a Internet se enruta directamente a través de Agent Gateway, en lugar de hacerlo a través de tu red de VPC.
Tráfico a todos los rangos de direcciones IP (ALL_TRAFFIC): Enruta todo el tráfico saliente que se origina en tus agentes a través de tu red de VPC, incluido el Internet público, las APIs de SaaS externas y las direcciones que no son RFC 1918.
- Enrutamiento y seguridad: Debido a que este parámetro de configuración enruta todo el tráfico saliente a tu VPC, eres responsable de administrar su enrutamiento y seguridad. Asegúrate de que tu red de VPC tenga una ruta predeterminada (0.0.0.0/0) para reenviar este tráfico a tus puertas de enlace de salida o dispositivos de seguridad (como firewalls de próximo salto o interfaces de Cloud Interconnect).
- Salida de Internet pública: Agent Gateway envía tráfico saliente a tu red de VPC, desde donde sale a la Internet pública a través de una puerta de enlace de Cloud NAT en la subred de adjunto de red de Private Service Connect. Si asignas direcciones IP externas estáticas a la puerta de enlace de Cloud NAT, los servicios remotos pueden incluir en la lista de entidades permitidas el tráfico de salida de tus agentes en función de estas direcciones IP de origen.
- Controles del servicio de VPC: El modo de salida debe establecerse en ALL_TRAFFIC para admitir los perímetros de servicio de los Controles del servicio de VPC.

Resolución de DNS y enrutamiento del tráfico

De forma predeterminada, Agent Gateway resuelve los nombres de dominio con el DNS recursivo público. Si tus agentes necesitan acceder a cargas de trabajo internas, herramientas privadas o APIs de Google alojadas en nombres de dominio privados en tu red de VPC (como extremos de corp.internal. o PSC), puedes configurar el intercambio de tráfico de Cloud DNS para reenviar consultas de DNS a las zonas administradas privadas de Cloud DNS de tu red.

En la siguiente tabla, se resumen los requisitos de intercambio de tráfico de Cloud DNS y el comportamiento del enrutamiento de tráfico para diferentes destinos cuando la conectividad de VPC se configura en el modo ALL_TRAFFIC:

**Tabla:** Resolución de DNS y enrutamiento de tráfico en el modo `ALL_TRAFFIC`
Destino de tráfico	¿Se requiere el intercambio de tráfico de Cloud DNS?	Resolución de DNS	Ruta de salida
Servicios de IP privada (RFC 1918/interna)	Sí (por ejemplo, `corp.internal.`)	Se resuelve con el intercambio de tráfico de Cloud DNS con la zona administrada privada de Cloud DNS de tu red de VPC de destino.	El tráfico ingresa a tu red de VPC a través del adjunto de red para conectarse a las cargas de trabajo internas.
Nombres de host públicos con IPs privadas (DNS de horizonte dividido)	No.	Se resuelve con el DNS recursivo público estándar en el proxy de puerta de enlace sin necesidad de intercambio de tráfico de Cloud DNS.	El tráfico ingresa a tu red de VPC a través del adjunto de red para conectarse a las cargas de trabajo internas.
Internet público y APIs de SaaS (dominios externos)	No.	Se resuelve con el DNS recursivo público estándar en el proxy de puerta de enlace sin necesidad de intercambio de tráfico de Cloud DNS.	El tráfico ingresa a tu red de VPC a través del adjunto de red y sale a la Internet pública con Cloud NAT configurado en la subred.
APIs deGoogle Cloud (estándar, sin Controles del servicio de VPC)	No.	Se resuelve con el DNS recursivo público estándar en el proxy de puerta de enlace sin necesidad de intercambio de tráfico de Cloud DNS.	El tráfico ingresa a tu red de VPC a través del adjunto de red y se enruta de forma privada con el Acceso privado a Google habilitado en la subred, sin usar Cloud NAT ni el intercambio de tráfico de DNS.
APIs deGoogle Cloud (con Controles del servicio de VPC)	Sí (para `googleapis.com.`)	Se resuelve en el rango restringido de la API de Google (`199.36.153.4/30`) o en los extremos internos de Private Service Connect con una zona privada de Cloud DNS.	El tráfico ingresa a tu red de VPC a través del adjunto de red para aplicar las reglas de seguridad del perímetro de los Controles del servicio de VPC¹.

¹ Si las solicitudes fallan con incumplimientos de los Controles del servicio de VPC, como NETWORK_NOT_IN_SAME_SERVICE_PERIMETER o SECURITY_POLICY_VIOLATED en compute.googleapis.com o dns.googleapis.com que hacen referencia al proyecto host, verifica que el proyecto host esté en el mismo perímetro que el proyecto de puerta de enlace.

Requisitos del certificado TLS

Cuando se enruta el tráfico de salida a través de HTTPS, Agent Gateway valida la cadena de certificados TLS del servidor de destino durante el protocolo de enlace TLS. Los requisitos de certificado para las conexiones HTTPS dependen de si tus extremos de destino usan autoridades certificadoras (AC) de confianza pública o AC privadas o autofirmadas.

AC públicas: De forma predeterminada, Agent Gateway confía en los certificados emitidos por autoridades certificadoras (AC) de confianza pública que cumplen con los requisitos estándar de certificados de servidor (incluido un nombre alternativo del sujeto [SAN] que coincida con el nombre de host de destino).
CAs privadas y certificados autofirmados: Si tu destino (agentes, herramientas o servidores de MCP en tu red de VPC) usa una CA privada o una PKI interna, puedes configurar anclas de confianza personalizadas con el parámetro de configuración tlsConfig en tu plantilla de conectividad.

Si haces referencia a un recurso TrustConfig de Administrador de certificados, puedes configurar Agent Gateway para que confíe solo en AC privadas específicas o combinar AC raíz privadas con AC de confianza pública (PUBLICLY_TRUSTED_ROOTS). Esto establece la confianza para los extremos públicos y privados.

Si tus agentes se conectan a las APIs de Google Cloud (*.googleapis.com) o a otros extremos HTTPS públicos, debes establecer additionalRoots enPUBLICLY_TRUSTED_ROOTS. Sin este parámetro de configuración, Agent Gateway no confía en los certificados firmados por Google para googleapis.com.

Ten en cuenta las siguientes limitaciones cuando uses tlsConfig:
- Cuando usas trustConfig para enrutar el tráfico a destinos que usan AC privadas, debes rotar los archivos PEM de forma manual. No se admite la rotación automatizada de archivos PEM con administradores de secretos, como Secret Manager de Google Cloud.
- El campo trustConfig es inmutable una vez que se configura en una plantilla de conectividad, y Agent Gateway no recoge automáticamente los cambios realizados en tlsConfig (como la actualización de additionalRoots) en una plantilla de conectividad adjunta. Para obtener instrucciones sobre cómo actualizar la configuración de TLS, consulta Actualiza la configuración de salida de VPC.

Si Agent Gateway no puede validar la cadena de certificados, la conexión falla.

Roles y permisos requeridos

Para configurar la conectividad de VPC para Agent Gateway, asegúrate de que la identidad que se usa para el aprovisionamiento y el agente de servicio de la puerta de enlace tengan los roles necesarios.

Implementaciones de proyectos independientes

En un proyecto independiente en el que la puerta de enlace, el adjunto de red y la red de VPC residen en el mismo proyecto, se aplican los permisos estándar de Agent Gateway. Para obtener más información, consulta Permisos necesarios.

Implementaciones de VPC compartida o entre proyectos

En una implementación de VPC compartida, puedes aprovisionar la Agent Gateway en un proyecto de servicio o en el proyecto host. Si aprovisionas la puerta de enlace en el proyecto host (donde también residen la red de VPC compartida, la subred y el adjunto de red), se aplican los permisos del proyecto independiente.

Si aprovisionas la Agent Gateway en un proyecto de servicio mientras la red de VPC de destino, el adjunto de red o las zonas del DNS privadas residen en el proyecto host (TARGET_VPC_PROJECT_ID), las identidades del proyecto de servicio no tienen permisos automáticamente para validar, adjuntar o establecer intercambio de tráfico con los recursos de red y DNS en el proyecto host. Otorga los siguientes roles en el proyecto host, además de los permisos estándar de Agent Gateway:

**Tabla:** Permisos necesarios para la VPC compartida y las implementaciones entre proyectos
Principal o identidad	Otorgar en el proyecto	Rol de IAM requerido	Objetivo
Identidad de aprovisionamiento¹ (Cuenta de usuario o cuenta de servicio de implementación)	Proyecto host (`TARGET_VPC_PROJECT_ID`)	Visualizador de la red de Compute (`roles/compute.networkViewer`) Lector de DNS (`roles/dns.reader`) Administrador del extremo regional de conectividad de red (`roles/networkconnectivity.regionalEndpointAdmin`) Administrador de redes del consumidor de conectividad de red (`roles/networkconnectivity.consumerNetworkAdmin`)	Permite la validación de backend de la red de VPC de destino, las subredes, el adjunto de red y las zonas del DNS privado durante la creación o actualización de la puerta de enlace.
Creador de adjuntos de red (Administrador que crea el adjunto de PSC)	Proyecto host (`TARGET_VPC_PROJECT_ID`)	Usuario de la red de Compute (`roles/compute.networkUser`)	Permite usar una subred de VPC compartida en el proyecto host para crear un adjunto de red de Private Service Connect.
Adjunto de red en el proyecto de servicio (recomendado)
Agente de servicio de Agent Gateway²	Proyecto host (`TARGET_VPC_PROJECT_ID`)	Usuario de la red de Compute (`roles/compute.networkUser`) Intercambio de tráfico de DNS (`roles/dns.peer`)	Permite que el agente de servicio de Agent Gateway use la subred del proyecto host para el adjunto de red, conecte la interfaz de Private Service Connect para enrutar el tráfico de salida y establezca un intercambio de tráfico con las zonas privadas de Cloud DNS en el proyecto host.
Adjunto de red en el proyecto host
Agente de servicio de Agent Gateway²	Proyecto host (`TARGET_VPC_PROJECT_ID`)	Administrador de red de Compute (`roles/compute.networkAdmin`) o un rol personalizado con lo siguiente: `compute.networkAttachments.get` `compute.networkAttachments.update` `compute.regionOperations.get` Intercambio de tráfico de DNS (`roles/dns.peer`)	Permite que el agente de servicio de Agent Gateway actualice el adjunto de red del proyecto host para permitir la conexión desde el proyecto de usuario de Agent Gateway, enrutar el tráfico de salida y establecer un intercambio de tráfico con las zonas privadas de Cloud DNS en el proyecto host.

¹ Para la identidad de aprovisionamiento, los roles básicos a nivel del proyecto, como Visualizador (roles/viewer) o Editor (roles/editor) en el proyecto host, también son suficientes.

² El agente de servicio de Agent Gateway tiene el siguiente formato: service-AGENT_GATEWAY_PROJECT_NUMBER@gcp-sa-agentgateway.iam.gserviceaccount.com, donde AGENT_GATEWAY_PROJECT_NUMBER es el número del proyecto en el que aprovisionas Agent Gateway. Para las implementaciones de VPC compartida, este proyecto puede ser un proyecto de servicio o el proyecto host.

Si conectas varios proyectos de servicio de Agent Runtime a un proyecto host de Agent Gateway, también debes otorgar acceso entre proyectos en el proyecto de puerta de enlace a cada agente de servicio de Agent Runtime. Para implementaciones a gran escala, consulta Escala proyectos de servicio de Agent Runtime con un Grupo de Google.

Configura la conectividad de VPC

Para implementar una Agent Gateway con una plantilla de conectividad, completa los pasos que se indican en las siguientes secciones.

Crea un adjunto de red de Private Service Connect

Crea un adjunto de red de Private Service Connect en tu red de VPC de destino.

Asegúrate de que tu adjunto de red cumpla con los siguientes requisitos:

Preferencia de conexión: Configura el adjunto de red para aceptar conexiones automáticamente (--connection-preference=ACCEPT_AUTOMATIC).
Requisito de la misma red de VPC: La subred del adjunto de red y la red de destino configurada para el intercambio de tráfico de DNS (targetNetwork) deben estar exactamente en la misma red de VPC. Si la subred del adjunto de red pertenece a una red diferente de la red de destino del intercambio de tráfico de DNS, la validación de la configuración falla.
Compatibilidad con la MTU de la red de VPC: Agent Gateway admite una unidad de transmisión máxima (MTU) de hasta 1,500 bytes para la red de VPC que contiene la subred del adjunto de red. Si esa red de VPC usa una MTU más grande, como marcos jumbo, comunícate con el equipo de Atención al cliente de Cloud para alinear el servicio de productor de Agent Gateway con tu MTU de VPC personalizada.
Requisitos de la subred: Ten en cuenta los siguientes requisitos para la subred del adjunto de red:
- Rango de subred: La subred del adjunto de red admite todos los rangos válidos.
- Tamaño de la subred: Agent Gateway requiere una subred /28 como mínimo para el adjunto de red. Una subred /28 proporciona 12 direcciones IP utilizables, lo que es suficiente para una sola instancia de Agent Gateway. Si planeas conectar varias puertas de enlace al mismo adjunto de red o subred, usa una subred más grande (como /26 o /24) para evitar el agotamiento de direcciones IP.
- Requisito de Acceso privado a Google: Debes habilitar el Acceso privado a Google (private_ip_google_access = true) en la subred que aloja el adjunto de red.
Implementaciones de VPC compartida: Para las implementaciones de VPC compartida, consulta Topologías de implementación de VPC compartida.

Anota el URI completo del recurso del adjunto de red (por ejemplo, projects/NETWORK_ATTACHMENT_PROJECT_NUMBER/regions/NETWORK_ATTACHMENT_REGION/networkAttachments/NETWORK_ATTACHMENT_NAME). Lo necesitarás cuando crees el recurso de plantilla de conectividad en un paso posterior.

Opcional: Configura el intercambio de tráfico de DNS

El intercambio de tráfico de DNS permite que Agent Gateway resuelva nombres de DNS con registros de una zona administrada privada de Cloud DNS en tu red de VPC. El intercambio de tráfico de DNS solo es necesario cuando tus agentes deben resolver nombres de dominio internos privados (como corp.internal.) o aplicar los Controles del servicio de VPC para las APIs de Google (googleapis.com.). No es necesario para los dominios públicos de Internet ni para las APIs de Google estándar sin Controles del servicio de VPC.

Agent Gateway admite el intercambio de tráfico de DNS transitivo solo hasta un salto transitivo, lo que significa un máximo de tres redes de VPC. Por ejemplo, vpc-net-a (la red de inquilinos de Agent Gateway) puede intercambiar tráfico con vpc-net-b (red conectada), que, a su vez, intercambia tráfico con vpc-net-c (red remota) para resolver las consultas de DNS en toda la cadena.

Para configurar el intercambio de tráfico de DNS, sigue estos pasos:

Configura tu zona del DNS privada en tu red de VPC de destino. Para agregar registros DNS a tu zona del DNS privada, consulta Agrega un conjunto de registros de recursos.
Recopila la siguiente información para configurar la plantilla de conectividad y habilitar el intercambio de tráfico:
- URI de la red de destino (targetNetwork): Ten en cuenta el URI completo del recurso de la red de VPC de destino en el siguiente formato: projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME. La red de destino siempre es la red de VPC que contiene la subred a la que hace referencia el adjunto de red. Si la red de destino es una red de VPC compartida, asegúrate de usar el ID del proyecto host de la VPC compartida correspondiente.
- Nombres de dominio: Uno o más sufijos de dominio para el intercambio de tráfico de DNS. Cada dominio debe terminar con un punto final (.) (por ejemplo, corp.internal. o googleapis.com.).
  
  Para obtener orientación adicional sobre cómo configurar el campo domains, consulta Patrones de dominio de intercambio de tráfico de DNS. Para implementaciones entre proyectos, como la VPC compartida, consulta Requisitos de zona del DNS y de intercambio de tráfico entre proyectos.

Opcional: Configura la confianza de TLS

Si tu destino de destino usa una CA privada o un certificado autofirmado, debes crear un recurso TrustConfig en el Administrador de certificados. El recurso TrustConfig define las anclas de confianza y los certificados que Agent Gateway usa para validar las conexiones TLS.

Prepara tus archivos de certificado en formato PEM:
- Almacén de confianza: Son los certificados de la AC raíz o intermedios en formato PEM. Agent Gateway confía en cualquier certificado de servidor cuya cadena de confianza conduzca a uno de estos certificados de la AC. El almacén de confianza debe contener al menos un certificado de la AC raíz o intermedio.
- Certificados incluidos en la lista de entidades permitidas (opcional): Son certificados de servidor en formato PEM en los que quieres confiar de forma explícita, como un certificado autofirmado.
Ejecuta el siguiente comando para crear el recurso TrustConfig. La TrustConfig debe crearse en el mismo proyecto y la misma región que la Agent Gateway y la plantilla de conectividad.
```
gcloud certificate-manager trust-configs create TRUST_CONFIG_NAME \
    --location=LOCATION \
    --trust-store="trust-anchors=ROOT_CERT_FILE" \
    --allowlisted-certificates=ALLOWLISTED_CERT_FILE
```
Reemplaza lo siguiente:
- TRUST_CONFIG_NAME: Es un nombre para el recurso TrustConfig.
- LOCATION: Es la región de la configuración de confianza (por ejemplo, europe-west1). Debe ser la misma región que la de Agent Gateway y la plantilla de conectividad.
- ROOT_CERT_FILE: Es la ruta de acceso al certificado de la AC raíz o intermedia con codificación PEM.
- ALLOWLISTED_CERT_FILE: Es la ruta de acceso a un certificado con codificación PEM en el que deseas confiar de forma explícita (opcional). Si no usas certificados de la lista de entidades permitidas, omite esta marca.
Para obtener más información sobre cómo administrar las configuraciones de confianza, consulta Crea y administra configuraciones de confianza.

Implementa Agent Gateway

Crea el archivo de configuración de la plantilla de conectividad:

Crea un archivo YAML llamado agw-connectivity-template.yaml:
```
name: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/agentConnectivityTemplates/CONNECTIVITY_TEMPLATE_NAME
accessPath: AGENT_TO_ANYWHERE
deploymentModel: CENTRALIZED
egressNetworkConfig:
  networkAttachment: projects/NETWORK_ATTACHMENT_PROJECT_NUMBER/regions/NETWORK_ATTACHMENT_REGION/networkAttachments/NETWORK_ATTACHMENT_NAME
  dnsPeeringConfig:
    domains:
      - DOMAIN_NAME
    targetNetwork: projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME
  vpcEgress: VPC_EGRESS_MODE
  tlsConfig:
    trustConfig: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
    additionalRoots: ADDITIONAL_ROOTS_OPTION
```
Reemplaza lo siguiente:
- AGENT_GATEWAY_PROJECT_NUMBER: Es el número de proyecto del proyecto de Google Cloud en el que aprovisionas la Agent Gateway. Para recuperar el número de tu proyecto, ejecuta lo siguiente: gcloud projects describe PROJECT_ID --format="value(projectNumber)".
- LOCATION: Es la región de la plantilla de conectividad (por ejemplo, europe-west1).
- CONNECTIVITY_TEMPLATE_NAME: Es el nombre del recurso de la plantilla de conectividad.
- accessPath: Es la ruta de acceso administrada para la plantilla de conectividad. Establécelo en AGENT_TO_ANYWHERE (las plantillas de conectividad solo se admiten para las puertas de enlace de salida).
- deploymentModel: Es el modelo de implementación de la puerta de enlace. Se establece en CENTRALIZED.
- networkAttachment: Es el URI completo del recurso del adjunto de red de Private Service Connect:
  - NETWORK_ATTACHMENT_PROJECT_NUMBER: Es el número del proyecto en el que creaste el adjunto de red. Este proyecto puede ser el mismo que el proyecto de Agent Gateway o uno diferente si aprovisionas Agent Gateway en un proyecto de servicio de VPC compartida y creas el adjunto de red en el proyecto host de VPC compartida.
  - NETWORK_ATTACHMENT_REGION: Es la región que contiene el adjunto de red.
  - NETWORK_ATTACHMENT_NAME: Es el nombre del adjunto de red.
  Nota: El campo networkAttachment es inmutable una vez que se configura tanto en la plantilla de conectividad como en el Agent Gateway. No puedes cambiar el adjunto de red de una puerta de enlace existente cambiando a una plantilla de conectividad diferente.
- DOMAIN_NAME: Es uno o más sufijos de dominio para el intercambio de tráfico de DNS (por ejemplo, corp.internal., googleapis.com. o ., opcional). Agrega un elemento de lista en domains para cada sufijo de dominio con el que quieras intercambiar tráfico. Cada valor debe terminar con un punto final (.) y tener una zona administrada privada de Cloud DNS correspondiente autorizada para la red de destino.
  
  Para obtener orientación adicional sobre cómo configurar el campo domains, consulta Patrones de dominio de intercambio de tráfico de DNS.
- targetNetwork: Es el URI de recurso completo de la red de VPC de destino para el intercambio de tráfico de DNS (opcional). La red de destino siempre es la red de VPC que contiene la subred a la que hace referencia el adjunto de red:
  - TARGET_VPC_PROJECT_ID: Es el ID del proyecto propietario de la red de VPC de destino. Si la red que contiene la subred a la que hace referencia el adjunto de red es una red de VPC compartida, TARGET_VPC_PROJECT_ID es el ID del proyecto host de la VPC compartida. Siempre especifica targetNetwork con el ID del proyecto en lugar del número del proyecto.
  - TARGET_VPC_NETWORK_NAME: Es el nombre de la red de VPC de destino.
- VPC_EGRESS_MODE: Establece el modo de enrutamiento de salida. Se establece en PRIVATE_RANGES_ONLY o ALL_TRAFFIC.
- tlsConfig: (Opcional) Es la configuración de TLS para la validación del certificado del servidor cuando se conecta a extremos privados a través de HTTPS:
  - TRUST_CONFIG_NAME: Es el nombre del recurso TrustConfig del Administrador de certificados que contiene tus certificados de la AC privada o anclas de confianza.
  - ADDITIONAL_ROOTS_OPTION: Especifica si se debe confiar en las raíces de AC de confianza pública, además de tu configuración de confianza personalizada:
  - Establece en PUBLICLY_TRUSTED_ROOTS (predeterminado) para confiar en los certificados validados por el parámetro trustConfig y todas las AC de confianza pública. Debes establecer additionalRoots en PUBLICLY_TRUSTED_ROOTS si tus agentes también se conectan a APIs deGoogle Cloud (*.googleapis.com) o a otros extremos HTTPS públicos. Sin este parámetro de configuración, Agent Gateway no confiará en los certificados firmados por Google para googleapis.com.
  - Establécelo en NO_ADDITIONAL_ROOTS para confiar solo en los certificados validados por el parámetro trustConfig.
  Nota: El campo trustConfig es inmutable una vez que se configura en una plantilla de conectividad, y Agent Gateway no detecta automáticamente los cambios in situ en tlsConfig (como la actualización de additionalRoots) mientras la plantilla de conectividad está conectada a una puerta de enlace. Para actualizar la configuración de TLS, consulta Actualiza la configuración de salida de VPC.
Crea la plantilla de conectividad:

Ejecuta el siguiente comando para crear la plantilla de conectividad:
```
gcloud network-services agent-connectivity-templates import CONNECTIVITY_TEMPLATE_NAME \
    --source="agw-connectivity-template.yaml" \
    --location=LOCATION
```
Reemplaza lo siguiente:
- CONNECTIVITY_TEMPLATE_NAME: Es el nombre del recurso de la plantilla de conectividad.
- LOCATION: Es la ubicación en la que deseas crear el recurso de plantilla de conectividad. Por ejemplo, europe-west1
Define el recurso de Agent Gateway:

Define un nuevo recurso de Agent Gateway en modo AGENT_TO_ANYWHERE creando un archivo de configuración YAML de puerta de enlace (por ejemplo, my-agent-gateway-vpc-egress.yaml) que haga referencia a la plantilla de conectividad:
```
name: AGENT_GATEWAY_NAME
protocols:
  - MCP
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
agentConnectivityTemplate: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/agentConnectivityTemplates/CONNECTIVITY_TEMPLATE_NAME
registries:
  - AGENT_REGISTRY_PATH
```
Reemplaza lo siguiente:
- AGENT_GATEWAY_NAME: Es el nombre del recurso de Agent Gateway.
- AGENT_GATEWAY_PROJECT_NUMBER: Es el número del proyecto de Google Cloud en el que aprovisionas la Agent Gateway y la plantilla de conectividad. Para las implementaciones de VPC compartida, este proyecto puede ser un proyecto de servicio o el proyecto host. Para recuperar el número de tu proyecto, ejecuta gcloud projects describe PROJECT_ID --format="value(projectNumber)".
- LOCATION: Es la ubicación de la plantilla de conectividad (por ejemplo, europe-west1).
- CONNECTIVITY_TEMPLATE_NAME: Es el nombre del recurso de la plantilla de conectividad.
  - AGENT_REGISTRY_PATH: Es la ruta de acceso a la instancia regional del registro de agentes en el mismo proyecto y región que la puerta de enlace, con el formato //agentregistry.googleapis.com/projects/PROJECT_ID/locations/LOCATION. Para obtener orientación, consulta Planifica la implementación de Agent Gateway.
Importa e implementa Agent Gateway:

Ejecuta el siguiente comando para crear el recurso de Agent Gateway según la especificación de YAML:
```
gcloud network-services agent-gateways import AGENT_GATEWAY_NAME \
    --source="my-agent-gateway-vpc-egress.yaml" \
    --location=LOCATION
```
Reemplaza LOCATION por la ubicación en la que deseas crear el recurso de Agent Gateway. Por ejemplo, europe-west1.

Consideraciones sobre la arquitectura y las redes

En esta sección, se proporcionan orientación sobre la arquitectura y patrones de redes avanzados para implementar Agent Gateway con conectividad de VPC.

Actualiza la configuración de salida de VPC

No se puede modificar una plantilla de conectividad en su lugar mientras un Agent Gateway hace referencia a ella, y el Agent Gateway no recoge automáticamente los cambios realizados en una plantilla de conectividad adjunta:

Actualiza el intercambio de tráfico de DNS, el modo de salida de VPC o la configuración de TLS (tlsConfig): En una plantilla de conectividad, el campo tlsConfig.trustConfig es inmutable una vez configurado, y las actualizaciones locales de tlsConfig (como agregar o cambiar additionalRoots) no las detecta un Agent Gateway adjunto. Para actualizar la configuración de intercambio de tráfico de DNS, el modo de salida de VPC o la configuración de tlsConfig en una puerta de enlace existente, crea una plantilla de conectividad nueva que use el mismo networkAttachment con la configuración actualizada y actualiza la Agent Gateway para que haga referencia a la plantilla nueva (o desvincula y vuelve a vincular la plantilla de conectividad).
Cambiar el adjunto de red: El networkAttachment en sí es mutable una vez que se configura en la plantilla de conectividad y en la Agent Gateway. Para cambiar a un adjunto de red diferente (o red de VPC de destino), debes crear una plantilla de conectividad nueva y un Agent Gateway nuevo.

Topologías de implementación de VPC compartida

En una arquitectura de VPC compartida, puedes aprovisionar la puerta de enlace de agentes en un proyecto de servicio o en el proyecto host. Cuando aprovisionas Agent Gateway en un proyecto de servicio, puedes crear el adjunto de red en el proyecto de servicio (recomendado) o en el proyecto host:

Recomendado: Adjunto de red en el proyecto de servicio:
1. Crea la subred en el proyecto host.
2. Crea el adjunto de red en el proyecto de servicio y haz referencia a la subred del proyecto host.
Adjunto de red en el proyecto host:
1. Crea la subred en el proyecto host.
2. Crea el adjunto de red en el proyecto host.

Cumplimiento de los Controles del servicio de VPC

Para aplicar los perímetros de los Controles del servicio de VPC en las comunicaciones de los agentes, asegúrate de lo siguiente:

Establece vpcEgress en ALL_TRAFFIC en tu plantilla de conectividad.
Dirige las solicitudes a la API de Google al rango de IP de restricted.googleapis.com (199.36.153.4/30) o a un extremo interno de Private Service Connect para las APIs de Google.
Configura la resolución de DNS para googleapis.com. Crea una zona de Cloud DNS privada en tu red de VPC que asigne *.googleapis.com a restricted.googleapis.com, y, luego, incluye googleapis.com. en el campo domains de tu plantilla de conectividad.

Para obtener más detalles sobre la configuración de DNS, consulta Configura DNS para googleapis.com en la documentación del Acceso privado a Google.
En el caso de las implementaciones de VPC compartida, el proyecto host que posee la subred del adjunto de red y el dnsPeeringConfig.targetNetwork deben estar en el mismo perímetro de servicio que el proyecto en el que implementas la Agent Gateway. Esto se aplica incluso cuando creas el adjunto de red en el proyecto de servicio, ya que la subred y la red de VPC aún pertenecen al proyecto host. Si tus zonas del DNS privadas se alojan en un proyecto de DNS independiente, incluye ese proyecto en el perímetro también.

Patrones de dominio de intercambio de tráfico de DNS

En esta sección, se describen los patrones de resolución de dominios y las opciones para configurar el campo domains en una plantilla de conectividad.

Configuración del nombre de dominio: Configura el campo domains en la plantilla de conectividad según las siguientes consideraciones:

Dominios internos privados: Para resolver los servicios internos privados alojados en tu red de VPC (por ejemplo, service.corp.internal), especifica el sufijo de tu dominio interno (como corp.internal.). Se debe autorizar una zona administrada de Cloud DNS privada de coincidencia exacta para este dominio en la red de VPC de destino.
DNS de horizonte dividido (dominio público con IP RFC 1918): Si usas una zona del DNS pública para alojar registros que apuntan a IPs privadas internas (como mcp.example.com que se resuelve en una dirección RFC 1918 para los certificados públicos del Administrador de certificados), la puerta de enlace resuelve estos registros automáticamente con el DNS recursivo público sin necesidad de intercambio de tráfico de DNS.
APIs deGoogle Cloud con Controles del servicio de VPC: Cuando ALL_TRAFFIC se configura para aplicar los Controles del servicio de VPC, las solicitudes a la API de Google deben resolverse en el rango de IP de restricted.googleapis.com (199.36.153.4/30) o en los extremos de PSC internos. Crea una zona privada de Cloud DNS en tu red de VPC que asigne *.googleapis.com a restricted.googleapis.com, y que incluya googleapis.com. en el campo domains de tu plantilla de conectividad.
Patrones de resolución de varios dominios: Si tu implementación requiere resolver varios sufijos de dominio privados, elige uno de los siguientes patrones:
- Intercambia el tráfico de varios dominios individuales: Especifica una lista de sufijos de dominio en el campo domains de dnsPeeringConfig (por ejemplo, corp.internal., prod.internal. y googleapis.com.). Cada dominio de la lista debe terminar con un punto final (.) y tener una zona privada administrada por Cloud DNS correspondiente autorizada para la red de VPC de destino.
- Sufijo superior consolidado (recomendado): Consolida los servicios internos en un sufijo de dominio superior compartido (como *.internal. o *.corp.internal.) y, luego, incluye ese dominio superior en la lista de domains.
- Intercambio de tráfico raíz general con una zona de reenvío privada: Incluye "." en el campo domains de la plantilla de conectividad y configura una zona de reenvío privada de Cloud DNS para el dominio raíz (.) en tu red de VPC que apunte a un agente de resolución recursivo ascendente (como 8.8.8.8 o un agente de resolución empresarial interno). Las zonas privadas más específicas de tu VPC coinciden primero con la coincidencia de sufijo más larga, mientras que las consultas públicas que no coinciden se resuelven a través del reenviador ascendente.
  
  Precaución: Evita configurar una zona privada autorizada para el dominio raíz (.). Una zona raíz autorizada solo resuelve los registros definidos en ella y devuelve NXDOMAIN para todos los demás dominios, lo que puede impedir que se resuelvan los extremos de SaaS externos y las APIs de Google Cloud .

Requisitos de zona del DNS y de intercambio de tráfico entre proyectos

El parámetro de configuración dnsPeeringConfig de la plantilla de conectividad no admite el intercambio de tráfico de Cloud DNS directo entre proyectos. Cuando importas la plantilla de conectividad, la validación falla si la subred a la que hace referencia networkAttachment pertenece a una red de VPC diferente de targetNetwork o si dependes de la vinculación de zonas del DNS entre proyectos de un servicio o proyecto externo.

La zona administrada para el dominio se debe crear en el proyecto host que posee targetNetwork. La zona administrada puede ser cualquiera de los siguientes tipos de zona:

Zona privada autorizada
Zona de reenvío
Zona de intercambio de tráfico de Cloud DNS: Debe estar asociada con la red de VPC del proyecto host y orientarse a una red de VPC de destino. La VPC de destino debe resolver la consulta directamente con una zona privada autorizada. No se admite el reenvío de la consulta a otra zona de intercambio de tráfico de DNS (encadenamiento) y se produce un error NXDOMAIN.

Escala proyectos de servicio de Agent Runtime con un Grupo de Google

Si conectas varios proyectos de servicio de Agent Runtime a un proyecto host de Agent Gateway y otorgas acceso entre proyectos a cada agente de servicio de forma individual, debes actualizar la política de IAM del proyecto host cada vez que agregues un proyecto. En las implementaciones a gran escala, también puedes alcanzar los límites de las políticas de IAM a medida que agregas vinculaciones de roles.

Para evitar actualizar la política de IAM del proyecto host para cada proyecto de servicio nuevo, puedes administrar el acceso a través de un solo grupo de seguridad de Google:

Crea un grupo de seguridad: Crea un grupo de seguridad en la Consola del administrador de Google o ejecutando el comando gcloud identity groups create.

Nota: Para agregar agentes de servicio a un grupo de Google, debes activar la opción miembros externos para el grupo.
Otorga al grupo acceso al proyecto host de Agent Gateway: Vincula el grupo al rol de visualizador de servicios de red (roles/networkservices.viewer) en AGENT_GATEWAY_PROJECT_ID:
```
gcloud projects add-iam-policy-binding AGENT_GATEWAY_PROJECT_ID \
    --member="group:GROUP_EMAIL" \
    --role="roles/networkservices.viewer"
```
Reemplaza lo siguiente:
- AGENT_GATEWAY_PROJECT_ID: Es el ID del proyecto host de Agent Gateway.
- GROUP_EMAIL: Es la dirección de correo electrónico de tu grupo de seguridad (por ejemplo, agw-cross-project-runtime@example.com).
Agrega el agente de servicio de Agent Runtime de cada proyecto de servicio al grupo: Para cada proyecto de servicio de Agent Runtime, agrega su agente de servicio al grupo de seguridad ejecutando el comando gcloud identity groups memberships add de la siguiente manera:
```
gcloud identity groups memberships add \
    --group-email="GROUP_EMAIL" \
    --member-email="service-AGENT_RUNTIME_PROJECT_NUMBER@gcp-sa-aiplatform.iam.gserviceaccount.com"
```
Reemplaza AGENT_RUNTIME_PROJECT_NUMBER por el número del proyecto de servicio de Agent Runtime.

¿Qué sigue?

Guía

Configura Agent Gateway con conectividad de VPC

Cómo funciona la conectividad de VPC

Modos de salida de VPC

Resolución de DNS y enrutamiento del tráfico

Requisitos del certificado TLS

Roles y permisos requeridos

Implementaciones de proyectos independientes

Implementaciones de VPC compartida o entre proyectos

Configura la conectividad de VPC

Crea un adjunto de red de Private Service Connect

Opcional: Configura el intercambio de tráfico de DNS

Opcional: Configura la confianza de TLS

Implementa Agent Gateway

Consideraciones sobre la arquitectura y las redes

Actualiza la configuración de salida de VPC

Topologías de implementación de VPC compartida

Cumplimiento de los Controles del servicio de VPC

Patrones de dominio de intercambio de tráfico de DNS

Requisitos de zona del DNS y de intercambio de tráfico entre proyectos

Escala proyectos de servicio de Agent Runtime con un Grupo de Google

¿Qué sigue?

Enruta el tráfico de Agent Runtime a través de Agent Gateway

Codelab: Controla las cargas de trabajo de agentes con Agent Platform

Codelab: Salida de Agent Gateway desde Agent Runtime hacia redes de VPC

Delega la autorización para Agent Gateway

Administra Agent Gateway

Supervisa Agent Gateway

Enruta el tráfico de Gemini Enterprise a través de Agent Gateway

Configura Agent Gateway con conectividad de VPC Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Cómo funciona la conectividad de VPC

Modos de salida de VPC

Resolución de DNS y enrutamiento del tráfico

Requisitos del certificado TLS

Roles y permisos requeridos

Implementaciones de proyectos independientes

Implementaciones de VPC compartida o entre proyectos

Configura la conectividad de VPC

Crea un adjunto de red de Private Service Connect

Opcional: Configura el intercambio de tráfico de DNS

Opcional: Configura la confianza de TLS

Implementa Agent Gateway

Consideraciones sobre la arquitectura y las redes

Actualiza la configuración de salida de VPC

Topologías de implementación de VPC compartida

Cumplimiento de los Controles del servicio de VPC

Patrones de dominio de intercambio de tráfico de DNS

Requisitos de zona del DNS y de intercambio de tráfico entre proyectos

Escala proyectos de servicio de Agent Runtime con un Grupo de Google

¿Qué sigue?

Enruta el tráfico de Agent Runtime a través de Agent Gateway

Codelab: Controla las cargas de trabajo de agentes con Agent Platform

Codelab: Salida de Agent Gateway desde Agent Runtime hacia redes de VPC

Delega la autorización para Agent Gateway

Administra Agent Gateway

Supervisa Agent Gateway

Enruta el tráfico de Gemini Enterprise a través de Agent Gateway

Configura Agent Gateway con conectividad de VPC