Cómo escapar de un contenedor
Los contenedores se usan ampliamente para aislar aplicaciones, pero muchos ingenieros argumentan que no deben tratarse como un límite de seguridad fuerte, especialmente para ejecutar código no confiable. Los comentaristas contrastan los contenedores con kernel compartido frente a las máquinas virtuales y las VM ligeras (p. ej., Firecracker, Kata), destacando que los escapes de contenedor suelen depender de malas configuraciones o de capabilities adicionales concedidas por comodidad, como el acceso al socket de Docker o SYS_ADMIN. La visión general es que los contenedores ofrecen un aislamiento significativo pero imperfecto y deben combinarse con una configuración adecuada, parches del host y, a veces, capas adicionales como gVisor para modelos de amenaza de mayor riesgo.
¿Son los contenedores un límite de seguridad?
- Fuerte desacuerdo en el hilo.
- Un lado: los contenedores “no son un límite de seguridad”, especialmente para código no confiable o multiusuario; comparten el kernel del host y exponen una gran superficie de ataque.
- Vista opuesta: los contenedores sí proporcionan límites de seguridad reales (namespaces, cgroups, seccomp, aislamiento del sistema de archivos), aunque no lo bastante fuertes para escenarios de “ejecutar código arbitrario no confiable” o RCE como servicio.
- Varios argumentan que hace falta matiz: los contenedores añaden aislamiento significativo, pero deben tratarse como una capa entre varias, no como un límite duro.
Contenedores frente a máquinas virtuales
- Muchos comentarios: las VM son un límite cualitativamente más fuerte porque no comparten el kernel; los ataques deben cruzar una interfaz más pequeña y más auditable (hipervisor + controladores de dispositivos).
- Los contenedores son “aislamiento con kernel compartido”; las escaladas de privilegios del kernel o el uso indebido de capabilities pueden permitir la salida.
- Se citan como ventajas de las VM sobre los contenedores, para problemas estilo Spectre/Meltdown, características de hardware como el cambio de contexto de VM y el aislamiento de caché.
- Se mencionan las VM ligeras (Firecracker, Kata) y gVisor como enfoques intermedios.
Capabilities, mala configuración y riesgo en el mundo real
- Todas las técnicas de escape del artículo requieren privilegios adicionales: SYS_ADMIN, SYS_MODULE, SYS_PTRACE, DAC_READ_SEARCH, el namespace PID del host o acceso a docker.sock.
- Los críticos señalan que esto no está habilitado por defecto, así que el artículo muestra “cómo abusar de malas configuraciones”, no fallos inherentes.
- Otros responden que esas malas configuraciones son extremadamente comunes: los ingenieros añaden capabilities para “hacer que funcione”, siguen tutoriales malos o necesitan herramientas de profiling/monitorización que requieren privilegios altos.
- La manipulación de iptables por parte de Docker y la exposición de puertos por defecto se citan como un “footgun” que ha provocado incidentes reales.
Exploits del kernel y defensa en profundidad
- Varios señalan que un contenedor “vanilla” con capabilities por defecto suele escaparse mediante bugs locales de escalada de privilegios del kernel (N-days o 0-days).
- Los contenedores rootless, los user namespaces y herramientas como Podman pueden limitar el radio de impacto, pero requieren una configuración correcta.
- Tendencia de consenso: los contenedores mejoran la seguridad para la mayoría de cargas de trabajo de servidor ordinarias, pero no bastan por sí solos para código hostil multiusuario; se recomiendan múltiples capas de aislamiento.
Miscelánea
- Deriva sobre los contenedores de envío literales y lo difíciles que son de escapar, usado como analogía para la seguridad en capas.