Seguridad en Contenedores, Aislamiento y Control de Recursos
Un contenedor no es una máquina virtual completa. Los contenedores son procesos convencionales de Linux que comparten el mismo kernel del sistema anfitrión, aislados mediante primitivas del sistema operativo: Namespaces (aislamiento de vista) y cgroups (control de recursos).
En entornos de producción, es fundamental configurar límites de hardware estrictos y restringir privilegios para evitar que un contenedor comprometido afecte al resto del servidor.
1. Los Dos Pilares del Aislamiento en Linux #
1┌─────────────────────────────────────────────────────────────────────────────┐ 2│ SISTEMA ANFITRIÓN (KERNEL LINUX) │ 3├──────────────────────────────────────┬──────────────────────────────────────┤ 4│ NAMESPACES (¿Qué puede VER el proceso?) │ CGROUPS V2 (¿Cuánto puede CONSUMIR?) │ 5│ - PID: Aísla la tabla de procesos │ - Memoria RAM máxima (ej. 512 MB) │ 6│ - NET: Interfaces y tablas de red │ - Cuota de CPU (ej. 1.5 núcleos) │ 7│ - MNT: Puntos de montaje de discos │ - Límite de I/O de disco (IOPS) │ 8│ - IPC / UTS / USER: Usuarios y host │ - Límite de subprocesos (PIDs) │ 9└──────────────────────────────────────┴──────────────────────────────────────┘
2. Límites de Recursos de Hardware y OOM Killer #
Si un contenedor sufre una fuga de memoria (Memory Leak) o un bucle infinito y no tiene límites configurados, consumirá el 100% de la RAM del servidor físico, provocando que el kernel invoque al OOM Killer (Out Of Memory Killer) y termine procesos críticos.
1# Limitar memoria a 512 MB y CPU a 1.5 núcleos 2docker run -d \ 3 --name app-segura \ 4 --memory="512m" \ 5 --memory-swap="1g" \ 6 --cpus="1.5" \ 7 --pids-limit=100 \ 8 -p 8080:8080 mi-app:latest
- Si el contenedor excede los 512 MB de memoria, Docker lo detiene inmediatamente con el código de salida
Exit Code 137(128 + SIGKILL 9).
3. Reducción de Capacidades del Kernel (Linux Capabilities) #
Linux divide los privilegios de superusuario en unidades independientes llamadas Capabilities. Por defecto, Docker otorga capacidades que la mayoría de aplicaciones web no necesitan (como manipular la hora del reloj del sistema o crear interfaces de red virtuales).
- Mejor Práctica de Hardening: Quitar todas las capacidades y habilitar solo las estrictamente necesarias:
1docker run -d \ 2 --name web-hardened \ 3 --cap-drop=ALL \ 4 --cap-add=NET_BIND_SERVICE \ 5 -p 80:80 nginx:alpine
--cap-drop=ALL: Elimina todas las llamadas privilegiadas al kernel.--cap-add=NET_BIND_SERVICE: Permite al proceso vincularse a puertos privilegiados () como el puerto 80 o 443.
4. Sistema de Ficheros de Solo Lectura (--read-only) #
Hacer que el sistema de archivos raíz del contenedor sea de solo lectura impide que un atacante inyecte binarios maliciosos o modifique código en tiempo de ejecución:
1docker run -d \ 2 --name api-segura \ 3 --read-only \ 4 --tmpfs /tmp:rw,noexec,nosuid,size=64m \ 5 mi-api:latest
5. Escaneo de Vulnerabilidades con Docker Scout #
Docker incluye la herramienta integrada Docker Scout para auditar vulnerabilidades conocidas (CVEs) en las dependencias de tus imágenes:
1# Análisis rápido de vulnerabilidades en la imagen 2docker scout quickview mi-imagen:latest 3 4# Listado detallado de CVEs y recomendaciones de remediación 5docker scout cves mi-imagen:latest
Resumen del tema
Conceptos clave #
- Namespaces vs cgroups: los Namespaces aíslan la visibilidad de procesos y redes; los cgroups limitan el consumo físico de CPU y RAM.
- Límites de Recursos: flags
--memory,--cpusy--pids-limitindispensables en producción para evitar ataques DoS o agotamiento de servidor. - Linux Capabilities: flags
--cap-drop=ALLy--cap-addpara restringir permisos a nivel de kernel. --read-only: congela el sistema de ficheros impidiendo la escritura de troyanos o scripts en disco.- Docker Scout: auditoría de seguridad automatizada de CVEs en imágenes base y dependencias.
Qué debes recordar #
Nunca ejecutes contenedores sin límites de memoria (--memory) ni en modo --privileged en producción; aplica siempre el principio de menor privilegio.