---
title: AI y Docker: protege tu entorno Linux de ataques usando sandboxes
url: https://soylinux.com/ai-docker-sandboxes-proteger-entorno-linux-ataques-2026/
date: 2026-10-20T11:02:13-04:00
modified: 2026-10-20T11:02:13-04:00
author: Alfonso Moreno | Sysadmin Senior
description: Sandboxes Docker (sbx) y gVisor runsc explicados: cómo aislar agentes de IA y código no confiado en tu servidor Linux con daemon.json y RuntimeClass.
image: https://soylinux.com/wp-content/uploads/2026/10/nf_2978.jpg
categories: DevOps
tags: agentes-ia, contenedores, docker, sandboxes, seguridad
language: es
site: Soy Linux
---

> En mayo de 2026 Docker publicó una comparación honesta donde reconocieron que un agente de IA con acceso de escritura a tu sistema puede ejecutar un `rm -rf` sin que nadie lo detenga. La solución que ellos mismos eligieron no fue endurecer Docker: fue crear **Docker Sandboxes** (`sbx`), un nuevo nivel de aislamiento basado en microVMs que corre encima del daemon estándar. Esta guía explica qué son los sandboxes para agentes de IA, cómo funciona gVisor como alternativa open source en servidores Linux, y los patrones exactos para implementarlo en tu homelab o cluster.

TL;DR — Lo que vas a tener al final

- **Tiempo de setup:** 30-60 minutos por servicio.
- **Requisitos:** Docker Engine 24+, kernel 5.15 o superior, RuntimeClass habilitado en el daemon.
- **Resultado:** contenedores con gVisor o runsc, sin acceso al host aunque el proceso se explote.
- **Troubleshooting:** si el contenedor no arranca con RuntimeClass, verifica que runsc esté instalado y que el daemon tenga –experimental habilitado.

## Por qué Docker clásico ya no alcanza para agentes de IA

Un contenedor Docker tradicional comparte el kernel con el host. Eso significa que si el código que corre adentro —sea un proceso tuyo o un agente de IA— logra un escape de contenedor, tiene acceso directo al kernel del host. Para servidores web o bases de datos ese riesgo es aceptable porque el código es determinista y auditado. Para un agente de IA que ejecuta código generado al vuelo, no.

El problema se agrava con el patrón Docker-in-Docker (DinD). Cuando un agente necesita, por ejemplo, ejecutar `npm install && npm run build` y el resultado es una imagen Docker, terminas necesitando que el contenedor pueda lanzar otros contenedores. La única forma práctica hoy es `--privileged`, que rompe casi todas las garantías de aislamiento. Lo que Docker Sandboxes resuelve es exactamente esto: cada sandbox corre su propio daemon en una microVM, así el agente tiene su “Docker dentro del Docker” pero la microVM es lo único que toca el host.

Los niveles de aislamiento que verás a lo largo de la guía, del más débil al más fuerte:

1. **Chroot** — solo aísla el filesystem. El proceso ve `/proc` completo del host.
2. **systemd-nspawn** — añade aislamiento de red y procesos (chroot con esteroides). Nativo en systemd.
3. **Docker con runc** — el default. Namespace + cgroups, pero comparte kernel.
4. **Docker con `--runtime=runsc`** — mismo CLI, runtime gVisor userspace. Sin acceso directo al kernel.
5. **Docker Sandboxes (`sbx`)** — microVM por agente. El nivel más fuerte que ofrece Docker hoy.
6. **Kata Containers / Firecracker** — microVMs explícitas. Más overhead, máxima isolation.

## Docker Sandboxes: qué es y cuándo usarlo

Docker Sandboxes es un producto nuevo (lanzado en marzo de 2026, versión estable 0.39.0 a agosto de 2026) que ejecuta agentes de IA dentro de microVMs. Cada sandbox obtiene su propio daemon Docker, su propio filesystem y su propia red — el agente puede construir contenedores, instalar paquetes y modificar archivos sin tocar tu sistema host.

El CLI se llama `sbx` y la barrera de entrada es baja:

```bash
# Instalar sbx (requiere login en Docker Hub)
curl -fsSL https://docs.docker.com/ai/sandboxes/install/ | bash

# Lanzar un agente dentro de un sandbox
cd ~/mi-proyecto
sbx run claude

# Ver sandboxes activos
sbx list

# Destruir un sandbox especifico (los recursos se liberan)
sbx rm <sandbox-id>
```

Docker publica explícitamente que `sbx` es **gratuito para uso comercial**; solo la gobernanza organizacional (control centralizado de políticas de red, filesystem y MCP para todos los desarrolladores de una empresa) requiere suscripción paga.

La limitación importante que debes conocer antes de adoptarlo: **Docker Sandboxes está disponible solo en macOS y Windows**. En Linux de escritorio existe la versión antigua (`docker sandbox`), pero en servidores Linux no hay `sbx` todavía. Para ese caso la respuesta es gVisor, que cubrimos en la siguiente sección.

## gVisor: el sandbox open source para servidores Linux

gVisor es un runtime de contenedores open source mantenido por Google que implementa la API de Linux en espacio de usuario (escrito en Go). Cuando un contenedor corre con `--runtime=runsc`, las llamadas al sistema del contenedor no van al kernel del host: las intercepta el proceso `gVisor Sentry`, que las procesa y solo emite al kernel real un subconjunto muy limitado de syscalls.

El tradeoff es conocido: **10-30% de overhead** comparado con runc, y **no todas las syscalls están soportadas**. Por eso no se usa para toda la carga, solo para cargas no confiadas (agentes de IA, código generado por LLM, workloads multi-tenant). Si tu aplicación necesita acceso directo a GPUs con CUDA moderno o a features kernel recientes, gVisor puede romperse; prueba primero con tu imagen.

### Opción A: configurar Docker daemon con gVisor en un servidor Linux

Esta es la vía más directa para un homelab o servidor único. El daemon Docker por defecto usa `runc`; puedes añadir `runsc` como runtime alternativo y elegirlo por contenedor.

```bash
# 1. Instalar gVisor en el host (Ubuntu/Debian)
curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor
  -o /usr/share/keyrings/gvisor-archive-keyring.gpg

echo "deb [arch=amd64 signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg]
  https://storage.googleapis.com/gvisor/releases release main" |
  sudo tee /etc/apt/sources.list.d/gvisor.list

sudo apt-get update && sudo apt-get install -y runsc
runsc --version   # verifica la version instalada
```

Una vez instalado `runsc`, edita `/etc/docker/daemon.json` para registrarlo como runtime adicional:

```bash
# Crear o editar la configuracion del daemon
sudo tee /etc/docker/daemon.json > /dev/null <<'EOF'
{
  "default-runtime": "runc",
  "runtimes": {
    "runsc": {
      "path": "/usr/bin/runsc"
    }
  }
}
EOF

# Reiniciar el daemon para que tome la nueva config
sudo systemctl restart docker
```

Ahora puedes lanzar cualquier imagen bajo gVisor sin cambiar tu workflow. El cambio es solo en el flag `--runtime`:

```bash
# Mismo contenedor de siempre, pero aislado por gVisor
docker run --rm --runtime=runsc hello-world

# Verificar que el proceso dentro ve un kernel falso
docker run --rm --runtime=runsc alpine uname -r
# Output esperado: 4.4.0 (gVisor reporta una version fija del kernel)
```

Si quieres que gVisor sea el runtime por defecto (no recomendado en producción mixta porque rompe imágenes que necesitan syscalls modernas), cambia `"default-runtime": "runc"` por `"default-runtime": "runsc"`.

### Opción B: Kubernetes RuntimeClass con gVisor

En un cluster Kubernetes la forma idiomática es declarar un `RuntimeClass` y referenciarlo desde los pods que ejecutan código no confiado. El flujo es: instalar `runsc` en los nodos, registrarlo en `containerd`, crear el `RuntimeClass`, y aplicar `runtimeClassName: gvisor` en los pods que corresponda.

```bash
# 1. Instalar runsc en cada nodo (mismo bloque de antes)
curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor
  -o /usr/share/keyrings/gvisor-archive-keyring.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg]
  https://storage.googleapis.com/gvisor/releases release main" |
  sudo tee /etc/apt/sources.list.d/gvisor.list
sudo apt-get update && sudo apt-get install -y runsc
```

Después registra `runsc` en la config de `containerd` (no en Docker):

```bash
# /etc/containerd/config.toml
sudo tee /etc/containerd/config.toml > /dev/null <<'EOF'
version = 2

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
    runtime_type = "io.containerd.runc.v2"

  [plugins."io.containerd.grpc.v1.cri".containerd.runsc]
    runtime_type = "io.containerd.runsc.v1"
EOF

sudo systemctl restart containerd
```

Crea el `RuntimeClass` en el cluster:

```bash
kubectl apply -f - <<'EOF'
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
EOF
```

Y referencia `gvisor` en los pods que ejecutan código generado o cargas multi-tenant:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: ai-agent-isolated
spec:
  runtimeClassName: gvisor
  containers:
  - name: agent
    image: mi-agente:latest
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"
      limits:
        cpu: "2"
        memory: "2Gi"
```

Verifica que el pod realmente corre bajo gVisor con un `exec`:

```bash
kubectl exec -it ai-agent-isolated -- uname -r
# Output esperado: 4.4.0 (el kernel reportado por gVisor, no el del nodo)
```

## Cómo elegir: árbol de decisión

Usa esta guía cuando vayas a decidir qué nivel de aislamiento aplicar a una carga concreta:

CargaRuntime recomendadoPor quéServicio interno de tu empresa, código auditado`runc` (default)Overhead cero, máxima compatibilidad. gVisor no aporta.Agente de IA que ejecuta código en tu máquinaDocker Sandboxes (`sbx`) en macOS/Windows, o `runsc` en LinuxEl agente puede hacer `rm -rf`; necesitas isolation real.Multi-tenant SaaS con código de usuariogVisor + Kubernetes `RuntimeClass: gvisor`Aislamiento por pod sin pagar VM completa por tenant.Workloads que necesitan GPUs modernas o syscalls kernel recientesKata Containers o VM completagVisor no soporta CUDA reciente ni algunas syscalls. La VM es más cara pero compatible.Homelab ocasional, sin agentes`runc` con `--read-only` + `--cap-drop=ALL` + usernsDefense in depth barato sin cambiar runtime.## Patrón práctico: agente de IA en homelab Linux

El setup mínimo para correr un agente de IA en tu servidor Linux con aislamiento decente, sin meterte en Kubernetes:

```bash
# 1. Instalar gVisor
curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor
  -o /usr/share/keyrings/gvisor-archive-keyring.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg]
  https://storage.googleapis.com/gvisor/releases release main" |
  sudo tee /etc/apt/sources.list.d/gvisor.list
sudo apt-get update && sudo apt-get install -y runsc

# 2. Registrar runsc en Docker
sudo tee /etc/docker/daemon.json > /dev/null <<'EOF'
{
  "default-runtime": "runc",
  "runtimes": {
    "runsc": { "path": "/usr/bin/runsc" }
  }
}
EOF
sudo systemctl restart docker

# 3. Crear un wrapper que siempre lanza agentes con gVisor
sudo tee /usr/local/bin/safe-agent > /dev/null <<'EOF'
#!/bin/bash
docker run --rm -it
  --runtime=runsc
  --read-only
  --cap-drop=ALL
  --security-opt=no-new-privileges
  --memory=2g --cpus=2
  -v "$PWD":/workspace:ro
  -w /workspace
  mi-imagen-agente "$@"
EOF
sudo chmod +x /usr/local/bin/safe-agent

# 4. Usar el wrapper
cd ~/mi-proyecto
safe-agent claude
```

Los flags combinados hacen lo siguiente: `--runtime=runsc` aísla syscalls, `--read-only` protege el filesystem, `--cap-drop=ALL` quita capabilities Linux innecesarias, `--security-opt=no-new-privileges` evita escaladas via setuid, y los límites de memoria/CPU evitan que un agente en loop consuma todo el host.

## Limitaciones reales que debes conocer

gVisor no es mágico. Antes de adoptarlo en producción revisa esto:

- **Performance**: 10-30% más lento que runc en throughput CPU puro. En I/O de red el overhead puede ser mayor.
- **Syscalls no soportadas**: CUDA nativo, algunos ioctl específicos, acceso directo a dispositivos pasan por un subconjunto limitado. Si tu imagen usa features modernas de GPU, prueba antes.
- **gVisor no aplica memory limits en algunos setups**: en K3s con containerd hay reportes de que los límites de memoria del pod no se enforce correctamente bajo runsc. Verifica con `kubectl describe pod` o con `docker stats`.
- **Rootless Docker + gVisor**: tiene bugs conocidos al momento de escribir esto (issue #12575 en google/gvisor). Si usas rootless Docker, quédate con runc o usa Kata.
- **DinD bajo gVisor**: requiere configuración adicional (montar el socket con raw sockets, ver docs de “Docker in gVisor”). No funciona out-of-the-box.

Docker Sandboxes (`sbx`) tiene sus propias limitaciones, distintas:

- **Solo macOS y Windows** en el cliente. Para servidores Linux hoy no hay `sbx`; usa el camino de gVisor.
- **Recursos por sandbox**: cada agente consume una microVM completa. No es viable para 100+ agentes concurrentes en una sola máquina.
- **Persistencia**: cada sandbox es ephemeral. Si tu agente necesita memoria entre sesiones, usa el sistema de checkpoints de `sbx` explícitamente.

## Checklist de adopción gradual

No intentes hacer todo el lunes. Empieza por lo que más reduce riesgo con menos fricción:

- **Hoy (15 min):** documentar qué cargas de tu stack ejecutan código generado o no auditado. Sin un mapa de esto, no sabes dónde aplicar el sandbox.
- **Esta semana (1 h):** instalar `runsc` y registrarlo como runtime alternativo en `/etc/docker/daemon.json`. Lanzar uno o dos contenedores de staging con `--runtime=runsc` para verificar que tu imagen no rompe.
- **Este mes (3 h):** migrar las cargas identificadas al wrapper `safe-agent` (o equivalente). Auditar los logs de runsc durante una semana buscando syscalls rechazadas.
- **Próximo trimestre:** si tienes Kubernetes, añadir el `RuntimeClass: gvisor` y aplicarlo a los deployments de agentes. Considerar Kata Containers para los workloads que no entran en gVisor.

El punto clave: los agentes de IA son la primera carga donde “Docker clásico” deja de ser suficiente. El isolation real no se logra con más flags de `docker run`, se logra con un runtime que intercepta syscalls antes de que toquen tu kernel. gVisor es la opción open source madura para Linux; Docker Sandboxes (`sbx`) es la opción gestionada si trabajas en macOS o Windows. Elige según tu plataforma y mide antes de comprometerte.

## ## Preguntas frecuentes

¿Qué es un sandbox de contenedor?Es un aislamiento extra entre el contenedor y el host. En vez de depender solo de los namespaces y cgroups del kernel, el contenedor corre dentro de una VM ligera o de un intérprete de syscalls, así que un exploit en el contenedor no toca el host.

¿Qué diferencia hay entre gVisor y runsc?gVisor es el proyecto que implementa el runtime: intercepta las llamadas al sistema y las ejecuta en un proceso usuario separado del kernel. runsc es el binario que levanta ese runtime para un contenedor. Son la misma tecnología en distinto nivel.

¿Cómo se activa en un Dockerfile?Con la instrucción RuntimeClass: se define un RuntimeClass en el clúster apuntando a runsc, y el manifiesto del pod lo referencia. En Docker Compose se define el runtime en el daemon.json y se usa runtime: runsc en el servicio.

¿Rinde peor que el runtime normal?Sí, tiene sobrecosto de CPU, típicamente entre 10 y 30% en tareas intensivas de syscalls. Para workloads de I/O y servicios de red el impacto es menor. En un homelab suele ser aceptable.

¿Sirve para cualquier agente de IA?Es exactamente el caso de uso: un agente que ejecuta código no confiable queda contenido aunque el código sea malicioso, porque el runtime no expone las syscalls reales al kernel del host.

Lee también

- [Ataques en la cadena de suministro: el caso TeamPCP contra el open source](https://soylinux.com/teampcp-arresto-australia-cadena-suministro-open-source-2026/)
- [Docker en producción: las 5 prácticas que separan junior de senior](https://soylinux.com/docker-produccion-5-practicas/)
- [Hardening de SSH: 7 cambios de seguridad para tu servidor Linux](https://soylinux.com/hardening-ssh-7-cambios-seguridad/)
- [Kubernetes Recipes: gVisor Runtime Sandboxed Containers](https://kubernetes.recipes/recipes/security/gvisor-container-runtime/)
- [Documentación oficial gVisor](https://gvisor.dev/docs/)
- [Docker Sandboxes: comparing sandboxing approaches](https://www.docker.com/blog/comparing-sandboxing-approaches-ai-agents/)