- El uso de arquitecturas rootless mediante user namespaces permite aislar procesos para que el usuario sea root dentro del contenedor pero un usuario normal en el host.
- La seguridad se refuerza mediante el uso de perfiles seccomp, la eliminación de capacidades de Linux innecesarias y la implementación de sistemas de archivos de solo lectura.
- Herramientas como Podman facilitan la gestión de contenedores sin daemon privilegiado, utilizando mecanismos como subuid, subgid y backends de red como pasta o slirp4netns.
La adopción masiva de la contenedorización ha dado un vuelco total a cómo desplegamos software, acelerando los ritmos de entrega de una forma bestial. Pero claro, no todo es color de rosa; este éxito ha puesto a los contenedores en el punto de mira de los ciberatacantes. Resulta alarmante que gran parte de las imágenes en producción arrastren vulnerabilidades críticas, lo que deja la puerta abierta a que un fallo menor se convierta en un desastre total si no aplicamos unas medidas de seguridad de contenedores Docker que sean realmente sólidas.
Para no meter la pata, es fundamental entender que la seguridad no es un parche que se pone al final, sino que debe estar integrada en todo el ciclo de vida. Desde el momento en que eliges la imagen base hasta que el contenedor está corriendo en un clúster, cada paso cuenta. En las siguientes líneas vamos a desgranar cómo blindar el entorno, evitando a toda costa que los procesos se ejecuten con privilegios excesivos y solucionando esos típicos quebraderos de cabeza con los permisos que vuelven loco a cualquiera.
Los pilares de la arquitectura que debemos proteger
Para que un entorno sea seguro, no basta con instalar un firewall y olvidarse. Hay que mirar debajo del capó y proteger cada pieza del puzzle. Primero tenemos la imagen del contenedor, que es básicamente el ADN de nuestra aplicación. Si la imagen viene contaminada o está obsoleta, todas las instancias que lancemos serán vulnerables. Por eso, lo ideal es usar imágenes base de confianza y pasarles el escáner con frecuencia.
Luego está el tiempo de ejecución o runtime, que hace de puente entre el sistema operativo del host y la aplicación. Si este componente tiene un agujero, el aislamiento se va al traste. Mantener el runtime actualizado es vital para evitar que un atacante pueda saltar del contenedor al host. De igual forma, la orquestación (como ocurre con Kubernetes) es un objetivo jugoso. Aquí la clave es no dar llaves maestras a todo el mundo y aplicar un control de acceso basado en roles (RBAC) muy estricto.
No podemos olvidar el sistema operativo del host, ya que es la base de todo. Si alguien toma el control del host, tiene el control de todos los contenedores. Usar una distro mínima, que exponga la menor superficie de ataque posible, es una jugada inteligente. Por último, la conectividad de red es donde ocurren muchos ataques. Implementar TLS/SSL y segmentar la red para que los contenedores no hablen con quien no deben es la única forma de evitar el movimiento lateral de un intruso.
El concepto de Rootless: Magia y Realidad
Seguramente te habrás dado cuenta de que algunas herramientas permiten lanzar contenedores sin usar sudo. Esto no es magia, es el modo rootless. A diferencia de Docker tradicional, que depende de un daemon corriendo como root (un punto único de fallo peligroso), el modo rootless ejecuta el contenedor como un proceso más de tu usuario normal. Esto significa que, si alguien logra escapar del contenedor, se encontrará con los permisos limitados de un usuario y no con el poder absoluto del administrador del sistema.
El corazón de todo esto son los user namespaces. Esta función del kernel de Linux permite que un proceso crea que es root (UID 0) dentro de su propio espacio, pero que para el sistema operativo real sea simplemente el usuario 1000, por ejemplo. Para que esto funcione, el sistema utiliza los archivos /etc/subuid y /etc/subgid, donde se definen rangos de IDs secundarios que el usuario puede gestionar. Si no tienes configurados estos rangos, el sistema te lanzará un error porque no sabrá a qué IDs mapear los usuarios internos del contenedor.
Redes y almacenamiento en entornos sin privilegios
La red es uno de los puntos más complicados cuando no eres root, ya que no puedes crear interfaces de red reales. Para solucionar esto, existen herramientas como slirp4netns y pasta. Mientras que slirp4netns es la opción clásica y estable, pasta es la evolución moderna que ofrece un rendimiento superior y mejor soporte para ICMP y UDP. Es importante saber que, en modo rootless, no puedes usar puertos privilegiados (aquellos por debajo del 1024). Si necesitas que tu web responda en el puerto 80, la mejor opción es usar un puerto alto (como el 8080) y redirigir el tráfico mediante un proxy o reglas de firewall en el host.
En cuanto al almacenamiento, el problema es que el modo rootless no puede usar el overlayfs nativo del kernel de la misma forma que root. Aquí entra en juego fuse-overlayfs, que es una implementación en espacio de usuario. Aunque es un pelín más lenta, es la que permite que las capas de las imágenes funcionen sin necesidad de permisos elevados. Para quienes buscan la máxima seguridad, lo ideal es configurar el sistema de archivos como solo lectura, obligando a la aplicación a escribir solo en directorios específicos mediante tmpfs.
Técnicas avanzadas de Hardening
Si quieres llevar la seguridad al siguiente nivel, tienes que hablar de seccomp y las capabilities. Seccomp actúa como un filtro que decide qué llamadas al sistema (syscalls) puede hacer el contenedor. Bloquear llamadas peligrosas evita que un proceso malicioso intente modificar el kernel. Por otro lado, las capabilities permiten desglosar el poder de root en trozos pequeños. En lugar de dar todo el poder, solo asignamos, por ejemplo, CAP_NET_BIND_SERVICE si solo necesitamos abrir un puerto, eliminando el resto de privilegios innecesarios.
Otra pieza clave para la producción es el linger de systemd. Normalmente, los servicios de usuario se mueren cuando cierras la sesión. Activar el linger permite que tus contenedores rootless sigan vivos y arranquen automáticamente tras un reinicio del sistema, sin necesidad de que haya un usuario logueado. Combinar esto con Quadlets permite gestionar los contenedores como si fueran servicios nativos de systemd y sus capacidades de sandboxing, facilitando enormemente la administración y el despliegue.
Solución de problemas y errores típicos
Es muy común toparse con el error de no subuid ranges found. Esto se arregla simplemente asignando un rango de IDs al usuario con el comando usermod. Otro dolor de cabeza es cuando el comando ping no funciona dentro del contenedor; esto pasa porque requiere la capacidad CAP_NET_RAW, que por defecto está desactivada en modo rootless. Puedes solucionarlo añadiendo la capacidad manualmente o ajustando el ping_group_range en el kernel del host.
Si notas que el rendimiento de las compilaciones es lento, probablemente sea por fuse-overlayfs. En esos casos, intentar usar el driver de almacenamiento nativo si el kernel lo permite puede marcar la diferencia. Finalmente, recuerda que el flag --privileged es totalmente incompatible con el modo rootless por diseño; si realmente necesitas acceso total al hardware, tendrás que ejecutar el contenedor como root, aunque esto rompa toda la estrategia de seguridad que hemos visto.
Construyendo imágenes blindadas
La seguridad empieza en el Dockerfile. Una regla de oro es crear imágenes minimalistas o usar imágenes «distroless». Estas últimas no incluyen ni siquiera un shell (sh o bash) ni gestores de paquetes, lo que deja al atacante sin herramientas si logra entrar. El uso de compilaciones multi-etapa (multi-stage builds) es fundamental: usas una imagen pesada para compilar tu código y luego mueves solo el binario final a una imagen vacía (scratch), eliminando todo el rastro de herramientas de desarrollo.
Es vital implementar la directiva USER para que el proceso no arranque como root dentro del contenedor. Además, se recomienda eliminar los permisos setuid y setgid de cualquier binario interno para evitar la escalada de privilegios. Para cerrar el círculo, integrar escaneos automáticos de vulnerabilidades (CVE) en el pipeline de CI/CD asegura que ninguna imagen con fallos críticos llegue jamás al entorno de producción.
La gestión de contenedores sin root es la estrategia más efectiva para reducir la superficie de ataque, ya que elimina la dependencia de un daemon privilegiado y limita el impacto de cualquier posible brecha mediante el uso de namespaces y la restricción de capacidades. Al combinar imágenes minimalistas, perfiles seccomp estrictos, redes optimizadas y una correcta configuración de los rangos de UID/GID, es posible desplegar aplicaciones altamente resilientes que protegen tanto la integridad del host como la de los datos procesados.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.