Aislar en un sandbox las acciones de un agente: límites de sistema de archivos, red y credenciales

Qué es

El sandboxing coloca los efectos secundarios de un agente detrás de límites del sistema operativo y de red, de modo que una acción equivocada o manipulada quede contenida. Se combinan tres capas. Sistema de archivos: un directorio de trabajo en el que el agente puede escribir, todo lo demás de solo lectura o invisible. Red: sin acceso saliente por defecto, con una lista de permitidos donde haga falta. Credenciales: sin secretos de larga vida dentro del sandbox; las llamadas autenticadas pasan por una herramienta o un proxy que retiene la credencial fuera. La documentación de Docker describe el perfil seccomp por defecto, que deshabilita alrededor de 44 de más de 300 llamadas al sistema, el control de capacidades con --cap-drop, y --privileged, que otorga a un contenedor todas las capacidades y el acceso a todos los dispositivos del host. gVisor es un núcleo de aplicación con una interfaz de tipo Linux, escrito en un lenguaje con seguridad de memoria y ejecutado en espacio de usuario, empleado a través de su runtime runsc con Docker o Kubernetes cuando se quiere un límite más fuerte que un núcleo de host compartido.

Por qué importa

Un agente lee contenido no confiable (páginas web, documentos, salida de herramientas) y puede ser dirigido por él. El sandbox convierte «el agente fue inducido a ejecutar un comando» de un incidente en una línea de registro. También absorbe los errores ordinarios: una ruta equivocada en una eliminación recursiva dentro de un contenedor desechable no cuesta nada.

Cómo aplicarlo

• Ejecutar la herramienta en un contenedor nuevo por tarea o sesión: usuario sin privilegios, todas las capacidades eliminadas, sistema de archivos raíz de solo lectura, un volumen escribible solo para el espacio de trabajo, límites de memoria y CPU, sin socket de Docker.
• Mantener el perfil seccomp por defecto o uno más estricto; no ejecutar sin confinamiento para hacer que algo funcione.
• Poner la red en «ninguna» por defecto; donde el agente necesite una API, enrutarla a través de un proxy de salida con lista de permitidos y registro, de modo que un «publica este archivo en esa URL» inyectado falle.
• No montar ningún secreto. Dar al sandbox un token de corta vida limitado al único recurso que necesita, o situar la llamada autenticada en una herramienta que se ejecute fuera del sandbox y valide sus argumentos.
• Tratar lo que sale del sandbox como no confiable: copiar solo los artefactos esperados, comprobar nombres y tamaños, no ejecutarlos nunca en el host.
• Para agentes multiinquilino o expuestos a internet, preferir un límite de núcleo en espacio de usuario o de máquina virtual antes que contenedores simples.

Trampas

El directorio personal de la persona usuaria montado dentro del sandbox. Variables de entorno heredadas del host que llevan credenciales de nube. Red «apagada» para el contenedor pero con un proxy que reenvía cualquier cosa. Contenedores de larga vida que acumulan estado y secretos entre tareas. Suponer que un límite de contenedor equivale a un límite de máquina virtual.