Descripción general de las zonas de pruebas

Muchas tareas de los agentes implican ejecutar código no confiable, ejecutar comandos, usar un navegador web o interactuar con entornos externos de formas que podrían representar riesgos de seguridad. Gemini Enterprise Agent Platform proporciona entornos de pruebas aislados para controlar estas cargas de trabajo de forma segura.

Las zonas de pruebas proporcionan entornos de ejecución seguros y aislados que se generan para realizar tareas específicas en nombre de un agente. Si ejecutas estas operaciones en una zona de pruebas, puedes proteger tu infraestructura y tus datos de acciones potencialmente maliciosas o erróneas que realice el agente. Las zonas de pruebas mitigan estos riesgos de las siguientes maneras:

  • Aislamiento: Cada zona de pruebas está aislada de otras zonas de pruebas y del sistema host. Las acciones que realiza un agente en una zona de pruebas no afectan a otros agentes ni a los usuarios que comparten los mismos recursos de entorno de ejecución.
  • Seguridad: Las operaciones dentro de la zona de pruebas están restringidas, lo que evita el acceso no autorizado a tus recursos. Todos los entornos de zona de pruebas usan una zona de pruebas de contenedores segura, lo que proporciona un límite de seguridad sólido. El código malicioso no puede acceder a datos sensibles ni credenciales dentro del entorno de ejecución.
  • Seguridad: Si un agente ejecuta un comando dañino o un bucle infinito, el impacto se contiene dentro de la zona de pruebas. Por ejemplo, el código mal escrito o malicioso podría consumir toda la CPU o la memoria disponibles.

Comparación entre la zona de pruebas y el entorno de ejecución

El Agent Runtime y una zona de pruebas difieren en su propósito y uso:

  • Agent Runtime: Es el entorno en el que se ejecutan la lógica principal, la toma de decisiones y la organización del agente. Es un entorno de confianza que ejecuta tu código y administra el ciclo de vida del agente.
  • Zona de pruebas: Es un entorno auxiliar que genera el agente o la plataforma para ejecutar tareas específicas y potencialmente inseguras. Las zonas de pruebas pueden ser de corta duración, basadas en sesiones o con estado durante varios días.

Por ejemplo, si un agente necesita calcular una fórmula compleja generando y ejecutando una secuencia de comandos de Python personalizada, debe ejecutarla en una zona de pruebas de ejecución de código, no en su propio entorno de ejecución. Además, si el agente usa una habilidad y una secuencia de comandos de shell, debe ejecutarlos en un entorno aprovisionado específicamente para esa sesión, con el acceso del usuario final.

Velocidades de aprovisionamiento de TTL y de la zona de pruebas

Los entornos de zona de pruebas tienen las siguientes características de tiempo de actividad (TTL) y aprovisionamiento:

  • TTL: Los TTL de las zonas de pruebas varían, desde 7 días para una imagen de contenedor personalizada hasta 14 días para una zona de pruebas de ejecución de código. Esto te permite reanudar el estado en un entorno de zona de pruebas varios días después para tareas de largo horizonte y entornos de shell reanudables.
  • Aprovisionamiento: La creación de una nueva zona de pruebas tarda hasta 2 minutos en aprovisionar recursos desde un inicio en frío, pero después de aprovisionarlos, las zonas de pruebas suelen iniciarse en segundos. Puedes ver la arquitectura subyacente en los siguientes proyectos de código abierto: AX y Substrate.

Funciones

Las zonas de pruebas ofrecen varias funciones, como zonas de pruebas predefinidas, contenedores personalizados, controles de seguridad empresarial y administración del ciclo de vida:

  • Ejecución de código: Permite que el agente genere y ejecute código en un entorno seguro. Esto es útil para cálculos matemáticos complejos, análisis de datos y otras tareas que requieren procesamiento.
  • Uso de la computadora: Permite que el agente interactúe con un navegador web para realizar tareas como completar formularios, buscar en la Web o navegar por flujos de trabajo de IU complejos.
  • Contenedores personalizados: Puedes "traer tu propio contenedor" para personalizar el entorno de ejecución con bibliotecas, herramientas o parámetros de configuración específicos. Usa esto para darle a tu agente un entorno de shell que contenga los comandos y las herramientas de tu imagen personalizada.
  • Controles del servicio de VPC: Configura perímetros de seguridad para proteger los datos sensibles y evitar la salida no autorizada de los entornos de zona de pruebas.
  • Claves de encriptación administradas por el cliente (CMEK): Protege los datos de la zona de pruebas en reposo con claves de encriptación administradas en Cloud Key Management Service (Cloud KMS).

Límites de seguridad, identidad y observabilidad

Cuando diseñes agentes que ejecuten código o comandos no confiables en una zona de pruebas, ten en cuenta cómo la plataforma de agentes separa la identidad de ejecución, el filtrado de salida de red y el registro de auditoría entre Agent Runtime y el contenedor de la zona de pruebas.

Identidad de ejecución y límites de credenciales

El código ejecutado dentro de una zona de pruebas se ejecuta en un proyecto de usuario administrado por Google dentro de un contenedor aislado de gVisor y no hereda la identidad ni las credenciales de tu agente superior. En la siguiente tabla, se resumen las identidades involucradas en las operaciones de la zona de pruebas:

Capa de identidad Principal Alcance y permisos
Identidad de Agent Runtime del agente superior Identidad del agente (principal://agents.global.org-ORG_ID.system.id.goog/...) o la cuenta de servicio personalizada o predeterminada adjunta a la instancia de ReasoningEngine Lo usa el código de organización que se ejecuta en Agent Runtime para llamar a las APIs de Google Cloud y administrar o invocar zonas de pruebas. Nunca se activa dentro del contenedor de la zona de pruebas.
Agente de servicio de la zona de pruebas service-PROJECT_NUMBER@gcp-sa-vertex-sandbox.iam.gserviceaccount.com Es el agente de servicio por proyecto administrado por Google que usa el plano de control de la zona de pruebas para las tareas de infraestructura, como extraer imágenes de contenedor personalizadas de Artifact Registry o usar claves de CMEK. Nunca es accesible para el código que se ejecuta dentro de la zona de pruebas.
Entorno de ejecución en la zona de pruebas Usuario de contenedor sin privilegios (como appuser en entornos de pruebas de shell) respaldado por una identidad de usuario sin privilegios (sandbox-untrusted) sin roles de Identity and Access Management (IAM) en tu proyecto Ejecuta código no confiable dentro del Pod de zona de pruebas. No tiene credenciales ambientales de Google Cloud ni permisos en tu proyecto o ReasoningEnginesuperior.

Ten en cuenta los siguientes límites de credenciales y autenticación cuando ejecutes código dentro de una zona de pruebas:

  • No hay credenciales de ambiente ni acceso a tokens del servidor de metadatos: El código de la zona de pruebas no tiene credenciales predeterminadas de la aplicación (ADC) para tu proyecto y no puede consultar el servidor de metadatos de Compute Engine (169.254.169.254:80) para crear tokens de acceso de OAuth 2.0, leer claves de cuentas de servicio ni inspeccionar metadatos del proyecto host.
  • Autenticación de llamadas entrantes: Tu agente o cliente se autentica en el plano de control y el plano de datos de la zona de pruebas con IAM (permiso aiplatform.sandboxEnvironments.execute, incluido en roles como roles/aiplatform.user) o un token de acceso de corta duración generado por generate_access_token o generate_browser_ws_headers.
  • Autentica llamadas salientes desde una zona de pruebas: Debido a que la zona de pruebas no tiene identidad de ambiente, cualquier llamada a la API externa que se realice directamente desde la zona de pruebas debe usar las credenciales que proporciones de forma explícita. Se recomienda realizar operaciones autenticadas de la API de Google Cloud en el agente superior en Agent Runtime y pasar solo los datos de entrada requeridos a la zona de pruebas. Si el código dentro de la zona de pruebas debe llamar directamente a un servicio externo, inserta tokens de corta duración y alcance limitado para esa ejecución específica en lugar de pasar claves de cuenta de servicio de larga duración.

Salida de red y lista de dominios permitidos

Las zonas de pruebas no proporcionan una propiedad de lista de dominios permitidos integrada en la zona de pruebas ni en el recurso SandboxEnvironmentTemplate. El comportamiento de la red de salida depende del tipo de zona de pruebas y de la configuración de egress_control_config en la plantilla:

  • Entornos de zona de pruebas de ejecución de código: Se ejecutan sin acceso a Internet saliente ni a la red de nube privada virtual (VPC).
  • Zonas de pruebas respaldadas por plantillas (Uso de computadoras, Zona de pruebas de shell y Contenedores personalizados): Inhabilitan el acceso a Internet saliente de forma predeterminada (internet_access es False).
  • Salida directa a Internet (internet_access: True sin network_attachment): Otorga a la zona de pruebas acceso de salida sin restricciones a las direcciones IP públicas (0.0.0.0/0), mientras que las políticas de red bloquean el acceso a los rangos de direcciones RFC 1918 privados (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) y al rango de metadatos de vínculo local (169.254.0.0/16). No puedes especificar una lista de dominios permitidos o rechazados directamente en egress_control_config.
  • Lista de dominios permitidos y filtrado de salida con controles de VPC: Para restringir una zona de pruebas a dominios (FQDN), URLs o rangos de IP específicos, configura egress_control_config.network_attachment en la plantilla para conectar toda la salida de la zona de pruebas a tu VPC a través de una interfaz de Private Service Connect (Private Service Connect). Una vez que el tráfico ingrese a tu VPC, aplica listas de entidades permitidas de dominios y políticas de salida con lo siguiente:
    • Cloud Next Generation Firewall (Cloud NGFW): Crea reglas de salida de la política de firewall de red global que permitan FQDN de destino o rangos de IP específicos y rechacen todo el resto del tráfico saliente (0.0.0.0/0).
    • Proxy web seguro (Secure Web Proxy): Enruta la salida desde la subred de Private Service Connect a través del Proxy web seguro para la inspección de TLS de capa 7 y la creación de listas de entidades permitidas a nivel de la URL.
    • Intercambio de tráfico de Cloud DNS: Configura dns_peering_configs y zonas privadas de Cloud DNS para que la zona de pruebas resuelva solo los nombres aprobados a través de tu VPC, en lugar de los agentes de resolución de DNS públicos.

Para obtener instrucciones de configuración paso a paso, consulta Configura los Controles del servicio de VPC y Private Service Connect con entornos de pruebas.

Registros de auditoría y detección de amenazas

La observabilidad y la supervisión de seguridad para las zonas de pruebas abarcan los planos de control y de datos de la API de Agent Platform, el agente superior en Agent Runtime y tu red de VPC.

Cobertura de los Registros de auditoría de Cloud

Agent Platform escribe entradas de Registros de auditoría de Cloud con el nombre del servicio aiplatform.googleapis.com y el tipo de recurso supervisado audited_resource para las llamadas a la API que se realizan a los recursos de la zona de pruebas, pero no genera entradas de registro de auditoría para los procesos internos que se generan dentro de un contenedor. En la siguiente tabla, se resume lo que se registra en cada límite:

Tipo de actividad Métodos o las operaciones de la API Categoría de registro Notas
Mutaciones del ciclo de vida de la zona de pruebas y la plantilla CreateSandboxEnvironment, DeleteSandboxEnvironment, SnapshotSandboxEnvironment, PauseSandboxEnvironment, ResumeSandboxEnvironment, CreateSandboxEnvironmentTemplate, UpdateSandboxEnvironmentTemplate, DeleteSandboxEnvironmentTemplate, DeleteSandboxEnvironmentSnapshot Actividad del administrador (ADMIN_WRITE) Siempre están habilitados de forma predeterminada. Registra la identidad del emisor, el nombre del recurso y los metadatos de la operación.
Lecturas de metadatos de plantillas y zonas de pruebas GetSandboxEnvironment, ListSandboxEnvironments, GetSandboxEnvironmentTemplate, ListSandboxEnvironmentTemplates, GetSandboxEnvironmentSnapshot, ListSandboxEnvironmentSnapshots Acceso a los datos (ADMIN_READ) Está inhabilitado de forma predeterminada. Habilita los registros de ADMIN_READ para aiplatform.googleapis.com para auditar quién inspecciona o enumera las zonas de pruebas.
Ejecución de comandos del plano de datos y autorización de acceso ExecuteSandboxEnvironment, BidiExecuteSandboxEnvironment, AuthorizeSandboxEnvironmentAccess, ExecuteCode Acceso a los datos (DATA_WRITE) Está inhabilitado de forma predeterminada. Habilita los registros de DATA_WRITE para aiplatform.googleapis.com con el objetivo de auditar las RPC de ejecución y la generación de tokens. En el caso de los recursos que se encuentran dentro de un perímetro de Controles del servicio de VPC, las cargas útiles de solicitud y respuesta se omiten de los registros de auditoría.
Procesos secundarios en el contenedor, escrituras de archivos y fotogramas de transmisión interactivos Subprocesos generados por un comando de shell, modificaciones del sistema de archivos y marcos individuales enviados a través de una sesión abierta de WebSocket, del protocolo de Herramientas para desarrolladores de Chrome (CDP) o de PTY No se registra en los Registros de auditoría de Cloud Los Registros de auditoría de Cloud registran la llamada a la API inicial (ExecuteSandboxEnvironment, BidiExecuteSandboxEnvironment o AuthorizeSandboxEnvironmentAccess), no las llamadas al sistema o los marcos de transmisión posteriores en el invitado.
Resultado de stdout y stderr del contenedor Flujos de salida y de error estándar de los comandos que se ejecutan dentro de la zona de pruebas Se muestra en la respuesta de la API de ejecución La recopilación automática de Cloud Logging (como reasoning_engine_stdout) solo se aplica al entorno de ejecución superior de ReasoningEngine y no recopila registros de los recursos secundarios de la zona de pruebas. Registra los resultados de los comandos de tu agente superior en Agent Runtime o consulta Administra entornos de pruebas.

Detección y supervisión de amenazas

Las zonas de pruebas aplican la contención del entorno de ejecución con el aislamiento del kernel de gVisor en los proyectos de usuario administrados por Google y no ejecutan un agente de detección de intrusiones de host integrado en el invitado ni un escáner de vulnerabilidades automático previo a la implementación. Para supervisar la actividad de la zona de pruebas y detectar amenazas, combina los siguientes controles:

  • Habilita los registros de auditoría de acceso a los datos: Habilita los registros de auditoría de Cloud ADMIN_READ y DATA_WRITE en aiplatform.googleapis.com para detectar la creación de entornos de pruebas no autorizados, la generación de tokens de acceso (AuthorizeSandboxEnvironmentAccess) o las solicitudes de ejecución.
  • Supervisa el comportamiento del agente superior: Habilita la detección de anomalías en agentes para analizar los seguimientos, las invocaciones de herramientas y los patrones de ejecución en tus agentes de Agent Runtime.
  • Inspecciona la salida de red en tu VPC: Conecta la salida de la zona de pruebas a tu VPC con una interfaz de Private Service Connect y habilita los registros de flujo de VPC en la subred de Private Service Connect, el registro de reglas de Cloud NGFW, los registros de acceso de Secure Web Proxy y el registro de consultas de Cloud DNS para detectar conexiones salientes anómalas o intentos de robo de datos.
  • Analiza las imágenes de contenedores personalizados antes de la implementación: Cuando uses contenedores personalizados (BYOC), habilita el análisis de vulnerabilidades en Artifact Registry para identificar paquetes vulnerables antes de hacer referencia al URI de la imagen en un SandboxEnvironmentTemplate.