Docker Sandboxes – Sandboxes desechables e aislados para agentes de IA
La nueva función Sandboxes de Docker busca ejecutar agentes de programación de IA dentro de microVMs desechables con cortafuegos salientes e inyección de credenciales, para que las herramientas no confiables no puedan acceder libremente a la máquina ni a los secretos del desarrollador. Los comentaristas valoran un aislamiento más fuerte que el de los contenedores tradicionales, pero critican duramente el inicio de sesión obligatorio en Docker, la herramienta de código cerrado y el soporte limitado para Linux, argumentando que eso socava la confianza y la viabilidad a largo plazo. Muchos señalan un ecosistema creciente de sandboxes de código abierto basados en VMs y contenedores, y algunos prefieren “vibecodear” sus propias soluciones adaptadas a flujos de trabajo y modelos de amenaza específicos.
Qué son realmente los Docker Sandboxes
- Varios comentaristas aclaran que esto no es una configuración normal de contenedores Docker.
- Cada agente/sesión se ejecuta en una microVM (estilo libkrun, con su propio kernel) sobre el hipervisor del host (Hypervisor.framework, WHP, KVM).
- Ofrece un aislamiento más fuerte que los contenedores simples y permite que el agente ejecute Docker dentro del sandbox sin comprometer el host.
Modelo de seguridad: VMs vs contenedores vs sandboxes del SO
- Muchos sostienen que los agentes de IA no confiables no deberían compartir un kernel con el host; se prefieren VMs/microVMs frente a contenedores basados en cgroups.
- Otros responden que los contenedores sin privilegios son “suficientemente buenos” para la mayoría de los desarrolladores, y que los escapes suelen deberse a 0-days y malas configuraciones.
- Algunos usan defensas en capas: VM + contenedores dentro + cortafuegos salientes + montajes limitados.
- Hay una discusión activa sobre bubblewrap, nono, gVisor, libkrun, Kata Containers, Incus/LXC, Flatpak, etc., como primitivas alternativas de sandboxing.
Requisito de inicio de sesión, código cerrado y gobernanza
- El inicio de sesión obligatorio en Docker para una herramienta local de desarrollo es ampliamente desaprobado.
- Algunos lo ven como una UX “basura” y temen futuros muros de pago/límites o cambios bruscos.
- Existe un producto empresarial de “AI Governance” para hacer cumplir centralmente políticas de sandbox.
Inyección de credenciales y controles de red
- La inyección de credenciales en el límite del proxy (secretos almacenados en el llavero del host, inyectados solo para hostnames/headers coincidentes) se considera una característica destacada.
- Hay debate sobre cuán robusto es esto frente a intentos ingeniosos de exfiltración; a algunos les preocupan formas de reflejar secretos de vuelta al agente.
- El cortafuegos saliente / las políticas de red de denegación por defecto son valorados; algunas alternativas implementan controles similares.
Soporte para Linux y brechas de plataforma
- Hay confusión y frustración con el soporte para Linux: la página de marketing inicialmente lo omitía, mientras que la documentación y los artefactos de lanzamiento indican compatibilidad con Ubuntu y algunas distribuciones basadas en RPM.
- Algunos se quejan de que no está disponible de forma amplia en todas las distribuciones o arquitecturas Linux.
Alternativas DIY y de código abierto
- Muchísimos usuarios han construido sus propios sandboxes (QEMU/KVM, microVMs tipo Firecracker, Incus, devcontainers, bubblewrap, Apple Container, Tart, podman+libkrun, etc.).
- Muchos enlazan a proyectos OSS que ofrecen agentes basados en microVM, proxies de credenciales, cortafuegos salientes o una mejor DX.
- Varios dicen que prefieren invertir en configuraciones abiertas y bajo su control en lugar de una herramienta propietaria y con acceso bloqueado por inicio de sesión.