5
Limitaciones fundamentales del aislamiento de contenedores
La contenedorización se ha convertido en el método dominante para empaquetar y entregar aplicaciones en arquitecturas de nube y microservicios. Los contenedores permiten agrupar código, bibliotecas y dependencias, garantizando una gran portabilidad y eficiencia operativa.
Sin embargo, la migración masiva de cargas de trabajo críticas a contenedores hace que la resistencia de los mecanismos de aislamiento sea una preocupación fundamental. Las investigaciones y encuestas a los equipos de DevOps y de seguridad muestran sistemáticamente que la seguridad de los contenedores sigue siendo una de las principales preocupaciones: las vulnerabilidades del kernel y del tiempo de ejecución, junto con los errores de configuración, conducen regularmente a brechas de aislamiento en el mundo real.
La pregunta clave es: ¿es absoluto el aislamiento de los contenedores?
La respuesta es no, y la razón reside en su arquitectura. En este artículo, profundizaremos en esta cuestión y exploraremos las medidas disponibles para mitigar los riesgos de vulnerabilidad.
Contenedores frente a máquinas virtuales: el núcleo compartido
Máquina virtual (VM):
-
Cada máquina virtual ejecuta su propio núcleo de sistema operativo, completamente separado del host.
-
El aislamiento lo impone un hipervisor (KVM, Xen, ESXi, etc.).
-
Un ataque normalmente debe dirigirse al hipervisor, lo que reduce significativamente los vectores de ataque.
Contenedores:
-
Un contenedor es un proceso aislado mediante primitivas del núcleo de Linux (namespaces, cgroups, etc.).
-
Un contenedor sólo contiene el espacio de usuario (bibliotecas, tiempo de ejecución, aplicación), pero comparte un núcleo con el host y otros contenedores.
-
Cualquier vulnerabilidad crítica del kernel se convierte automáticamente en un vector potencial de ataque para todos los contenedores del nodo.
La elección arquitectónica de un kernel compartido es lo que hace que el aislamiento de los contenedores no sea fundamentalmente absoluto: la explotación exitosa de una vulnerabilidad del kernel permite a un atacante eludir los límites de cualquier espacio de nombres.
El papel de los espacios de nombres y los Cgroups en la creación del aislamiento
La base del aislamiento de contenedores en Linux descansa sobre Namespaces y Cgroups.
-
Namespaces - Aislamiento de la vista de sistema: PID, Monte, Red, Usuario, IPC, UTS, y otros. Los procesos "ven" sólo su propio espacio: su sistema de ficheros, sus PIDs, su nombre de host y su red.
-
Cgroups - Control y limitación de recursos: CPU, memoria, E/S, recuento de procesos, etc.
Los espacios de nombres crean la ilusión de un sistema separado, y los Сgroups evitan que un contenedor acapare los recursos del host. Sin embargo, es crucial tener en cuenta que los espacios de nombres son un mecanismo de aislamiento, no un mecanismo de seguridad completo contra la elusión deliberada de barreras. No previenen la explotación de vulnerabilidades del kernel, no resuelven problemas con excesivos privilegios de root o contenedores privilegiados, no filtran llamadas al sistema y no gestionan políticas de acceso.
Por lo tanto, namespaces y Сgroups son meramente una capa base que debe ser fortificada con:
-
Filtrado de llamadas al sistema (Seccomp)
-
Políticas MAC (AppArmor/SELinux)
-
Restricciones de capacidad
-
Idealmente, User Namespaces + modo rootless
Seguridad de la plataforma de contenedores: amenazas críticas y vectores de ataque
La superficie de ataque de una plataforma de contenedores es multicapa. Se pueden identificar las siguientes superficies principales
-
Runtime y kernel (runc, containerd, CRI-O, kernel Linux).
-
Cadena de suministro de imágenes.
-
Configuración de contenedores y orquestadores.
-
Nube e infraestructura (IAM, API, almacenamiento, red).
Visión general de los vectores de ataque y vulnerabilidades críticas: Fuga de contenedores
Los vectores típicos en un entorno de contenedores incluyen: explotar un CVE en el kernel de Linux o en el tiempo de ejecución del contenedor; utilizar imágenes inseguras (paquetes obsoletos, kits de exploits); errores de configuración en Kubernetes/Docker (privilegios excesivos, montaje del sistema de archivos del host, pila de red del host); y compromiso del registro y CI/CD.
Es importante entender que una fuga de contenedores es a menudo una combinación de factores:
Vulnerabilidad del Kernel/Runtime + Configuración deficiente (ejecución como root, --privilegiado, montaje del sistema de archivos del host, falta de MAC/Seccomp).
Vulnerabilidades de la cadena de suministro
La cadena de suministro de imágenes de contenedores es uno de los principales riesgos porque las imágenes base de los registros públicos suelen contener CVE conocidas. Las dependencias (módulos pip/npm/gem/go) se extraen de forma transitoria y no siempre están controladas. Y lo que es más peligroso, el malware puede estar "latente" y manifestarse únicamente en tiempo de ejecución.
Por lo tanto, las siguientes buenas prácticas son obligatorias en producción:
-
Escaneo de imágenes en busca de CVEs, utilizando herramientas como Trivy, Clair, Grype, etc.
-
Utilización de registros con aplicación de políticas, como Harbor, Quay o GHCR.
-
Firma y verificación de imágenes antes del despliegue.
Errores de configuración y contenedores privilegiados
¡El error más común que abre ampliamente la puerta a vulnerabilidades es ejecutar procesos dentro del contenedor como root! Si la aplicación en el contenedor se lanza con derechos de superusuario, al comprometer el contenedor, el atacante obtiene root dentro del contenedor. Un escape exitoso fuera del contenedor entonces simplifica significativamente la escalada a la raíz del host.
Prohibir el lanzamiento de aplicaciones como root y utilizar UID/GID sin privilegios es la regla básica de un hardening adecuado.
Los contenedores privilegiados que utilizan la bandera --privileged prácticamente desactivan los mecanismos de aislamiento clave, específicamente algunos Cgroups, AppArmor/SELinux y restricciones Seccomp. Esto le da al contenedor acceso directo a los dispositivos del host y a los pseudo-sistemas de archivos (/proc, /sys, /dev, etc.). Desde un contenedor privilegiado, es fácil montar discos host y modificar el sistema de archivos y las configuraciones.
En esencia, un contenedor privilegiado equivale a una escalada de privilegios intencionada. Recuerda, esto sólo es aceptable en escenarios raros y bien aislados, y ciertamente no en un entorno multi-tenant.
También hay errores de configuración "silenciosos" que pueden hacer que el entorno del contenedor sea extremadamente vulnerable, incluso sin utilizar la bandera --privileged. Los más peligrosos son:
-
Montar hostPath a directorios sensibles del host, como /etc o /var/run/docker.sock.
-
Otorgar Capacidades innecesarias, por ejemplo, CAP_SYS_ADMIN, que virtualmente otorga derechos de root en el host.
-
Uso injustificado de los modos hostNetwork o hostPID.
Estas configuraciones aparentemente menores pueden permitir a un atacante escapar del contenedor y obtener el control del kernel o de todo el sistema host.
Comparación de arquitecturas: Docker vs. Podman
Las diferencias arquitectónicas entre Docker y Podman influyen directamente en el modelo de amenazas. Docker, con su demonio de altos privilegios, presenta el principal riesgo: un único punto de fallo.
Docker y el modo rootful
En la arquitectura clásica, o estándar, de Docker, la CLI de Docker se comunica con el demonio dockerd a través del socket /var/run/docker.sock o TCP. El demonio dockerd se ejecuta como usuario root y realiza las operaciones principales:
-
Creación/eliminación de contenedores
-
Creación de imágenes
-
Gestión de redes/volúmenes
-
Interacción con registros
De ello se deduce que el acceso directo a la API de Docker equivale a un acceso de root casi completo al host, lo que permite a un atacante montar el sistema de archivos, lanzar contenedores privilegiados, etc. En este escenario, el demonio se convierte en un único punto de fallo: si se ve comprometido, el atacante obtiene acceso al host.
Por lo tanto, Docker requiere un estricto control de acceso al socket, habilitación obligatoria de MAC y Seccomp, y restricción de Capacidades. Fundamentalmente, es esencial minimizar el número de usuarios y servicios con acceso a la API de Docker.
Podman sin demonio: el enfoque nativo de Linux
Podman fue desarrollado por Red Hat y la comunidad como una alternativa más segura y "nativa" de Linux. Se diseñó originalmente con una arquitectura sin demonio, lo que significa que no hay un demonio persistente y centralizado. En su lugar, los contenedores son procesos hijos del usuario que ejecutó el comando. La base es una profunda integración con systemd, donde las unidades y los servicios se crean directamente.
Esto elimina el punto único de fallo que presenta el demonio raíz y se alinea mejor con el modelo Unix tradicional: "quien lanzó el proceso es su dueño".
Modo sin raíz: Los espacios de nombres de usuario como principal barrera de seguridad
El modo sin raíz es esencialmente la respuesta lógica al peligro fundamental: "¿Qué pasa si el contenedor se escapa?".
El papel de los espacios de nombres de usuario y la mitigación de daños
Los espacios de nombres de usuario aíslan UID/GID y permiten la reasignación de UID. Por ejemplo, si un proceso dentro de un contenedor tiene UID 0 (root), ese mismo proceso se mapea a un UID sin privilegios del rango subuid/subgid en el host.
Por lo tanto, incluso si un atacante dentro del contenedor tiene privilegios de root y logra explotar una vulnerabilidad de tiempo de ejecución/núcleo para escapar al nivel del host, continúa operando como un usuario sin privilegios en el host.
De este modo, muchas cadenas de explotación, incluida runc-escape, se rompen o tienen un impacto significativamente reducido. Esto se debe a que el atacante no puede sobrescribir binarios/configuraciones propiedad de root, no puede montar sistemas de archivos, o gestionar dispositivos sin Capacidades, y las políticas MAC continúan operando también en el host.
Podman sin raíz: Limitaciones y la pila de red
Podman se diseñó desde el principio centrándose en operaciones sin raíz. Los contenedores son creados y gestionados por un usuario sin privilegios, los espacios de nombres de usuario están habilitados por defecto, y SELinux/AppArmor y Cgroups se utilizan en la medida de lo posible sin acceso root.
Sin embargo, hay algunas desventajas en este esquema. Cuando un contenedor sin root opera dentro del rango subuid/subgid, es posible que se produzcan errores de mapeo si la imagen contiene archivos con valores UID/GID que caen fuera de este rango.
Otro inconveniente indirecto es que un usuario sin privilegios no puede configurar libremente los espacios de nombres de red. Desde principios de 2025, Podman utiliza la pasta de pila en espacio de usuario como sustituto de slirp4netns. Este plugin opera completamente en espacio de usuario, pero gracias a la interfaz tap y al empalme de copia cero, ofrece un rendimiento de red casi nativo. No obstante, aún es posible que se produzcan ralentizaciones en el rendimiento, que están definitivamente garantizadas si los usuarios siguen utilizando slirp4netns.
Docker sin raíz: implementación y requisitos
Docker también soporta un modo rootless completo, en el que el demonio dockerd y los contenedores se lanzan dentro de un espacio de nombres de usuario sin los privilegios del usuario root del host. Es importante destacar que esto difiere de la antigua función userns-remap, en la que el propio demonio seguía teniendo privilegios.
Desde el punto de vista de la seguridad, esto garantiza que una brecha en el contenedor no resultará en una escalada automática al nivel de usuario root del host. En el caso de un ataque exitoso a dockerd en modo rootless, sólo se accederá a los recursos del usuario sin privilegios, no a todo el sistema.
La elección entre los modos rootful y rootless es principalmente un equilibrio entre maximizar el rendimiento y limitar al máximo el daño potencial en el caso de una brecha.
Conclusiones y recomendaciones de refuerzo
El análisis confirma que el aislamiento de los contenedores no es absoluto debido a su arquitectura. Dado que los contenedores comparten el núcleo del sistema anfitrión, las vulnerabilidades a nivel del núcleo o del tiempo de ejecución pueden, por definición, "ver" a través de los espacios de nombres, violando los límites de seguridad esperados.
En la práctica, la mayoría de los ataques con éxito están relacionados con una combinación de una vulnerabilidad conocida (kernel/runc) y una configuración débil (root, --privileged, hostPath).
Un modelo de seguridad de contenedores fiable debe construirse como un sistema multicapa:
Capa 1 - Segmentación: (namespaces, cgroups)
Capa 2 - Políticas y filtrado: (Seccomp, MAC, Capacidades)
Capa 3 - Restricción de privilegios arquitectónicos: (mediante modo sin raíz y espacios de nombres de usuario)
Lista de comprobación: endurecimiento del host para contenedores Docker y Podman
- Sin raíz por defecto
Considera Podman o Docker en modo rootless como el modelo por defecto para cargas de trabajo internas y multi-tenant.
- Endurecimiento y parcheado del kernel
Actualice rápidamente el kernel (Dirty COW, Dirty Pipe y otros CVE similares casi siempre se solucionan con parches). Utilice distribuciones con un buen historial de parches de seguridad (RHEL, OpenSUSE, Ubuntu LTS, etc.).
- Adoptar distribuciones de SO inmutables especializadas
Para mejorar la seguridad del entorno de contenedores, utilice distribuciones de SO inmutables como openSUSE MicroOS o Flatcar Linux. Su sistema de archivos raíz es de sólo lectura por defecto, lo que reduce significativamente la superficie de ataque. El mecanismo clave son las actualizaciones atómicas: se crea una nueva imagen del sistema operativo y la actualización se aplica por completo o se revierte por completo, lo que evita la corrupción del sistema y acelera la recuperación.
- Principio del mínimo privilegio
Nunca utilice el indicador --privileged en producción, excepto en entornos altamente especializados y aislados. Evite ejecutar aplicaciones dentro de contenedores como usuario root y utilice un sistema de archivos de sólo lectura, el conjunto mínimo de Capacidades y perfiles Seccomp estrictos.
- Políticas MAC y Seccomp
Habilite y configure SELinux\AppArmor para contenedores. Utilice perfiles Seccomp, idealmente personalizados y basados en las llamadas al sistema reales de la aplicación, no sólo en los valores predeterminados de Docker.
- Seguridad de la cadena de suministro
Implemente el escaneado de imágenes de contenedores. Limite las fuentes de imágenes base a registros oficiales o internos y habilite la firma y verificación de imágenes antes de su despliegue.
- Supervisión del tiempo de ejecución
Emplee herramientas de detección de anomalías e IDS/EDR de contenedores (Falco, Sysdig Secure o Aqua Security) que puedan detectar intentos de fuga de contenedores y supervisar la ejecución de comandos maliciosos. Rastree el tráfico de red atípico, las llamadas inesperadas al sistema y el acceso a archivos confidenciales.
El futuro del aislamiento: Kata Containers, gVisor y Micro-VMs
El modo sin raíz reduce significativamente el riesgo de que el host se vea totalmente comprometido, pero no lo resuelve todo, ya que las dependencias del núcleo del host permanecen y algunas clases de ataques no se eliminan.
Por lo tanto, los enfoques híbridos están ganando popularidad para las cargas de trabajo críticas:
- Kata Containers: Cada pod o contenedor se lanza dentro de una micro-VM ligera con un kernel separado, combinando las ventajas de las VMs y los contenedores.
- gVisor: Un kernel sandbox escrito en Go que actúa como capa intermedia entre la aplicación y el verdadero kernel Linux.
Estas soluciones reducen la dependencia del núcleo compartido y nos acercan al modelo de aislamiento de máquinas virtuales, al tiempo que conservan la naturaleza declarativa y la comodidad de los orquestadores de contenedores.
Convierta la orientación de este artículo en seguridad para el mundo real en su próxima implantación.
Consigue un VPS o Servidor Dedicado y empieza a configurar una plataforma de contenedores segura hoy mismo.
Pasar a la selección de configuración
Nuevos Posts:
Docker vs. Podman: Una guía completa para la contenedorización sin demonio
