Docker Para Agentes y Bots (Container Sandboxing)

1. Visión general del concepto y problema sistémico

Ejecutar agentes autónomos, scrapers, bots y scripts de generación de código directamente en el sistema operativo del servidor (por ejemplo, llamando directamente a python agent.py o node bot.js) crea amenazas críticas:

• Errores catastróficos e inyecciones: un modelo con acceso a herramientas de ejecución de comandos shell puede accidentalmente eliminar el directorio de trabajo del proyecto, cambiar permisos en /etc/shadow o filtrar variables de entorno del host.
• Conflictos de dependencias ("Dependency Hell"): un bot requiere Node.js 18 y Python 3.10, otro requiere Node.js 22 y bibliotecas del sistema Chromium para Playwright. Intentar desplegarlos en un mismo host rompe los paquetes del sistema.
• Agotamiento de memoria (Fork Bombs): un ciclo autónomo infinito puede crear miles de procesos paralelos, causando un Kernel Panic o un bloqueo total del servidor.

Docker para agentes y bots proporciona contenedorización determinista y aislamiento confiable (Sandboxing). Utilizando primitivas integradas del núcleo de Linux, el contenedor crea una cápsula efímera ligera, donde el agente obtiene todas las utilidades necesarias, pero no puede afectar al sistema host o a servicios vecinos.

2. Taxonomía arquitectónica y modelo mental

La arquitectura de aislamiento seguro del agente se basa en tres niveles de control del núcleo de Linux:

┌─────────────────────────────────────────────────────────────┐
│                 DOCKER AGENT SANDBOX ARCHITECTURE           │
├─────────────────────────────────────────────────────────────┤
│ 1. Proceso de Aislamiento (Linux Namespaces):               │
│    • PID (El agente ve solo sus propios procesos)           │
│    • NET (Pila de red aislada, veth pairs)                  │
│    • MNT (Sistema de archivos raíz propio rootfs)           │
├─────────────────────────────────────────────────────────────┤
│ 2. Enclosure de Recursos (Control Groups - cgroups v2):     │
│    • Límite de memoria (por ejemplo, max 1.5GB RAM)         │
│    • Cuota de CPU (por ejemplo, max 1 core)                 │
│    • Límite de PIDs (protección contra fork infinito)       │
├─────────────────────────────────────────────────────────────┤
│ 3. Capa de Endurecimiento de Seguridad:                      │
│    • Usuario No Privilegiado (`USER nonroot` en lugar de UID 0) │
│    • Sistema de Archivos Raíz Solo Lectura (`--read-only`)  │
│    • Capacidades de Linux Eliminadas (`--cap-drop=ALL`)     │
├─────────────────────────────────────────────────────────────┤
│ 4. Integración con el Host: Volúmenes Nombrados y Chequeos de Salud │
└─────────────────────────────────────────────────────────────┘

1. Espacios de Nombres (Linux Namespaces):
   • Proporcionan virtualización de procesos, red y sistema de archivos. El agente dentro del contenedor se ve a sí mismo como un sistema operativo separado y no tiene acceso a los procesos del host.
2. Grupos de Control (cgroups v2):
   • Cuotas de hardware estrictas: límites de RAM, CPU y número de hilos. Si el script del agente comienza a filtrar memoria, el OOM-killer de Linux mata solo el contenedor, sin afectar a los servicios principales del servidor.
3. Contenedores Efímeros Desechables (Throwaway Sandboxes):
   • Ejecución con la bandera --rm. Después de ejecutar el código, el contenedor se autodestruye junto con todos los cambios temporales.
4. Políticas de Reinicio (Restart Policies):
   • Para bots de larga duración, la directiva restart: unless-stopped en docker-compose.yml garantiza el levantamiento inmediato del servicio tras el reinicio del VPS.

3. Pipeline técnico y mecánica interna

El ciclo de vida de ejecución segura de código no verificado en la sandbox del agente:

1. Formación de la tarea y creación de la configuración: El agente de IA genera un script (por ejemplo, código Python para analizar datos financieros).
2. Preparación del volumen aislado: El sistema host crea una carpeta temporal /tmp/sandbox-run-981, escribe el script allí y establece permisos para el usuario no privilegiado UID 1000.
3. Ejecución de un contenedor desechable protegido: El orquestador inicia el comando con un restablecimiento completo de privilegios:

   docker run --rm \
     --network none \
     --memory 512m \
     --cpus 1.0 \
     --pids-limit 64 \
     --read-only \
     --tmpfs /tmp:rw,noexec,nosuid,size=64m \
     --user 1000:1000 \
     -v /tmp/sandbox-run-981:/app:ro \
     python:3.12-slim python /app/script.py
   

4. Ejecución aislada: El script se ejecuta:
   • La red está completamente desconectada (--network none), lo que imposibilita la fuga de datos a la nube del atacante.
   • El sistema de archivos es solo de lectura (--read-only).
   • La escritura está permitida solo en un pequeño disco temporal en RAM (/tmp).
5. Lectura de la salida y limpieza: Los flujos STDOUT y STDERR se envían de vuelta al núcleo del agente, tras lo cual el directorio temporal se elimina en una fracción de segundo.

4. Escenarios prácticos de ingeniería en producción

01. Stack de producción de bot de Telegram resistente a fallos

Despliegue del bot utilizando docker-compose.yml:

services:
  bot:
    build: .
    restart: unless-stopped
    environment:
      - BOT_TOKEN=${BOT_TOKEN}
      - DATABASE_URL=postgres://user:pass@db:5432/botdb
    depends_on:
      db:
        condition: service_healthy
    deploy:
      resources:
        limits:
          memory: 512M

  db:
    image: postgres:17-alpine
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d botdb"]
      interval: 10s

volumes:
  pgdata:

• El bot se reinicia automáticamente en caso de fallos inesperados de memoria, y los datos de la base se almacenan en un volumen persistente pgdata.

02. Ejecución aislada de un agente de navegador Playwright

Pruebas automatizadas y scraping de SPA complejas:

• El agente levanta un contenedor con Chromium en modo headless.
• Las pestañas del navegador colgadas o las animaciones pesadas solo utilizan la memoria virtual asignada al contenedor, sin sobrecargar la estación de trabajo.

03. Ejecución por lotes de scripts de usuario no verificados

Plataforma de pruebas de código en línea:

• Cada prueba de usuario se ejecuta en su propio contenedor con un tiempo de espera estricto de 5 segundos, lo que imposibilita el bloqueo del servidor debido a ciclos infinitos while(true).

5. Errores comunes, trampas y seguridad

• Pérdida de datos por ausencia de volúmenes (Volume Absence): Si se despliega un contenedor de base de datos sin montar un volumen persistente (volumes: - db_data:/var/lib/postgresql/data), en la primera actualización de la imagen o con el comando docker compose down, toda la base de datos del cliente se borrará para siempre.
• Ejecución por defecto como usuario Root: Si en el Dockerfile no se especifica la instrucción USER appuser, los procesos dentro del contenedor se ejecutan con privilegios de superusuario (UID 0). En caso de una vulnerabilidad del núcleo (Container Escape), un atacante obtiene inmediatamente acceso root completo en el servidor host.
• Desbordamiento de disco por imágenes huérfanas: Las construcciones regulares de imágenes de agentes dejan gigabytes de capas "huérfanas". Configure un comando de limpieza semanal: docker system prune -af --volumes.
• Ignorar .dockerignore: Si no se crea un archivo .dockerignore, las carpetas node_modules, .git y los archivos de secretos locales .env se copiarán dentro de la imagen pública del contenedor durante la construcción.