DEVOPS 12 min

Qué es Docker: Arquitectura, Namespaces, cgroups y Seguridad en Contenedores

Guía técnica y arquitectónica de Docker: cómo funcionan los Namespaces, cgroups v2 y Overlay2 en el kernel de Linux, comparativa de aislamiento frente a VMs y los 5 pilares para blindar contenedores en producción.

Escrito por Samir El Azem Crovetto • Senior Backend Engineer & DevSecOps

La Desmitificación del Contenedor: Qué es Realmente Docker

Durante años, la explicación habitual para introducir Docker ha sido definirlo como "una máquina virtual ligera". Esta metáfora comercial, aunque comprensible para una primera aproximación conceptual, es técnicamente inexacta y esconde el verdadero funcionamiento de los contenedores en los sistemas operativos modernos.

Un contenedor Docker no es una máquina virtual. No emula hardware, no ejecuta un kernel propio ni requiere la intervención de un hipervisor (como KVM, ESXi o Hyper-V) para traducir instrucciones de CPU.

Un contenedor es, en esencia, un proceso estándar de Linux aislado mediante primitivas del propio kernel, que comparte los recursos del sistema anfitrión (Host OS) pero opera dentro de una vista restringida del árbol de procesos, de la red, de los puntos de montaje y de los límites de memoria y cómputo.

Docker revolucionó la industria del software no porque inventara el concepto de aislamiento —mecanismos como chroot existían en Unix desde 1979, seguidos por FreeBSD Jails en 2000 y Solaris Zones en 2004—, sino porque transformó estas capacidades complejas del kernel en un estándar unificado, reproducible e inmutable: el formato de imagen y el ciclo de vida de los contenedores que hoy gobierna la Open Container Initiative (OCI).

Los Tres Pilares en el Kernel de Linux: Namespaces, cgroups v2 y Overlay2

Para comprender cómo Docker aísla y ejecuta aplicaciones, es imprescindible descender al nivel del kernel de Linux y examinar las tres tecnologías fundamentales sobre las que se construye:

flowchart TD
    subgraph Docker_Engine ["Docker Engine & Runtime OCI"]
        CLI[Docker CLI / API Client] -->|Unix Socket / HTTP| D[Docker Daemon - dockerd]
        D -->|gRPC| C[containerd]
        C -->|shim| R[runc - OCI Reference Runtime]
    end

    subgraph Linux_Kernel ["Kernel de Linux (Host)"]
        R -->|Aislamiento de Vista| NS[Linux Namespaces<br/>PID, NET, MNT, IPC, UTS, USER]
        R -->|Gobernanza de Recursos| CG[cgroups v2<br/>CPU, Memoria, I/O, PIDs]
        R -->|Restriccion de Syscalls| SC[seccomp & AppArmor<br/>Filtro de llamadas al sistema]
    end

    subgraph Storage ["Almacenamiento en Disco"]
        R -->|Copy-on-Write| OV[Overlay2 Storage Driver<br/>lowerdir + upperdir + merged]
    end

    classDef engine fill:#1e1e2e,stroke:#6366f1,stroke-width:2px,color:#cdd6f4;
    classDef kernel fill:#181825,stroke:#a6e3a1,stroke-width:2px,color:#cdd6f4;
    classDef storage fill:#181825,stroke:#f9e2af,stroke-width:2px,color:#cdd6f4;
    class Docker_Engine engine;
    class Linux_Kernel kernel;
    class Storage storage;

1. Linux Namespaces: La Ilusión del Aislamiento de Vista

Los Namespaces dividen los recursos globales del sistema operativo para que cada contenedor perciba un entorno exclusivo. Linux proporciona siete espacios de nombres principales:

  • PID Namespace (Procesos): El proceso principal de la aplicación dentro del contenedor adquiere el identificador PID 1 (como si fuera el proceso init/systemd del sistema). Sin embargo, desde la perspectiva del host, ese mismo proceso tiene un PID estándar (por ejemplo, PID 48291). El contenedor no puede ver ni interactuar con los procesos que se ejecutan fuera de su namespace.
  • NET Namespace (Red): Asigna al contenedor su propia tabla de enrutamiento, interfaces de red virtuales (veth), reglas de firewall (iptables/nftables) y puertos de enlace independientes.
  • MNT Namespace (Puntos de Montaje): Aísla el sistema de archivos del contenedor, permitiendo que monte su propio directorio raíz (/) sin interferir con el disco del host.
  • IPC Namespace (Comunicación Inter-Procesos): Restringe semáforos, colas de mensajes y memoria compartida POSIX entre contenedores.
  • UTS Namespace (Hostname): Permite que cada contenedor defina su propio nombre de host y dominio sin alterar los del sistema anfitrión.
  • USER Namespace (Identidades de Usuario): Mapea los identificadores de usuario (UID) y grupo (GID) dentro del contenedor con IDs no privilegiados en el host. Esta es una pieza clave para mitigar brechas de seguridad: un proceso que cree ser root (UID 0) dentro del contenedor puede ser en realidad el UID 10001 en el kernel del host.
  • CGROUP Namespace: Oculta la jerarquía global de cgroups para prevenir fugas de información sobre la topología del host.

2. Control Groups (cgroups v2): Gobernanza de Hardware

Mientras que los namespaces determinan qué puede ver un proceso, los Control Groups regulan cuánto puede consumir:

  • Límites de Memoria (memory.max y memory.high): Impiden que un contenedor sature la RAM física del servidor. Si un contenedor supera su límite estricto, el kernel invoca al OOM Killer (Out of Memory) para finalizar exclusivamente el proceso infractor sin desestabilizar a los demás servicios.
  • Cuotas de CPU (cpu.max): Asignan fracciones o núcleos completos de CPU mediante el planificador CFS (Completely Fair Scheduler), evitando que un bucle infinito en una aplicación degrade el rendimiento del clúster.
  • Límites de E/S (io.max): Garantizan que las lecturas y escrituras en disco de un proceso no monopolicen el ancho de banda del almacenamiento.
  • Límites de Procesos (pids.max): Protegen al sistema contra ataques de agotamiento de recursos o Fork Bombs, restringiendo el número total de subprocesos concurrentes que un contenedor puede instanciar.

3. Overlay2: El Sistema de Capas Inmutables (Copy-on-Write)

Las imágenes de Docker no son paquetes monolíticos; están compuestas por una pila de capas inmutables de solo lectura indexadas por su hash criptográfico SHA-256.

El controlador de almacenamiento Overlay2 combina estas capas mediante tres directorios:

  1. lowerdir (Capas de la imagen): Capas de solo lectura que contienen el sistema base, las dependencias y el binario compilado. Son compartidas en memoria entre múltiples contenedores basados en la misma imagen.
  2. upperdir (Capa del contenedor): Una capa efímera de lectura y escritura asignada al contenedor cuando se inicia. Si la aplicación escribe un log o crea un archivo temporal, el archivo se crea únicamente en este directorio.
  3. merged (Punto de montaje unificado): La vista combinada que la aplicación ve como un sistema de archivos tradicional.
  4. Mecanismo Copy-on-Write (CoW): Si el contenedor necesita modificar un archivo perteneciente a una capa inferior (lowerdir), Overlay2 realiza una copia del archivo en la capa superior (upperdir) antes de aplicar la modificación, preservando intacta la imagen original.

Contenedores vs. Máquinas Virtuales: El Modelo de Amenazas

La elección entre contenedores y máquinas virtuales no responde únicamente a criterios de rendimiento o eficiencia operativa; define el modelo de aislamiento y la superficie de exposición de la infraestructura.

Vector de Comparación Máquinas Virtuales (KVM / VMware) Contenedores Docker / OCI
Núcleo del Sistema Kernel independiente y dedicado por cada VM Kernel compartido con el sistema anfitrión (Host OS)
Frontera de Aislamiento Aislamiento por hardware asistido por CPU (Intel VT-x, AMD-V) Aislamiento lógico por software (Namespaces + cgroups)
Tiempo de Arranque 30 - 120 segundos (arranque de BIOS, kernel e init) 10 - 500 milisegundos (ejecución directa de un proceso)
Sobrecarga de Memoria Alta: gigabytes reservados para el SO huésped (Guest OS) Prácticamente nula: solo consume la memoria de la aplicación
Impacto de Escape (Breakout) El compromiso de la VM queda contenido dentro del hipervisor Un fallo en el kernel del host (Kernel LPE) compromete a todos los contenedores

El Riesgo Estructural del Kernel Compartido

Dado que todos los contenedores de un nodo comparten el mismo kernel, un contenedor no proporciona una frontera de seguridad tan estricta como una máquina virtual.

Si un atacante logra ejecutar código dentro de un contenedor y explota una vulnerabilidad de escalada de privilegios en una llamada al sistema (syscall) del kernel de Linux (como fallos históricos en netfilter, io_uring o eBPF), puede escapar del namespace y obtener control absoluto (root) sobre el servidor anfitrión.

Por esta razón, en arquitecturas empresariales y pipelines de DevSecOps, es imperativo tratar a los contenedores bajo el principio de Zero Trust, asumiendo que el proceso puede ser vulnerado y limitando al máximo sus privilegios.

Los 5 Pilares de Hardening en Contenedores para Producción

Para mitigar los riesgos inherentes al kernel compartido, la ingeniería de contenedores en producción debe adoptar cinco controles técnicos rigurosos:

1. Ejecución Obligatoria sin Root (Non-Root User)

Por defecto, si no se especifica la directiva USER en el Dockerfile, el proceso dentro del contenedor se ejecuta con el UID 0 (root). Si el contenedor no tiene activado el User Namespace Remapping y el atacante consigue escapar del contenedor, será automáticamente root en el servidor anfitrión.

# Crear un grupo y usuario de sistema dedicado con UID no privilegiado
RUN groupadd -g 10001 appgroup && \
    useradd -u 10001 -g appgroup -s /sbin/nologin -d /app appuser

USER 10001:10001

2. Adopción de Imágenes Mínimas y Distroless

El 90% de las vulnerabilidades reportadas por escáneres de seguridad en imágenes estándar (como ubuntu:latest o python:3.11) no provienen de la aplicación, sino de las herramientas del sistema operativo base: gestores de paquetes (apt, apk), intérpretes de comandos (/bin/sh, /bin/bash) y utilidades de red (curl, wget, netcat).

Las imágenes Distroless (mantenidas por Google o Chainguard) eliminan por completo shells y binarios innecesarios. Contienen estrictamente el runtime necesario para ejecutar la aplicación (como Node.js o el binario estático de Go), privando al atacante de las herramientas básicas para descargar payloads o establecer consolas reversas (reverse shells).

3. Supresión de Capacidades del Kernel (Linux Capabilities)

En Linux, los privilegios tradicionales de root están subdivididos en capacidades independientes (Capabilities). Por defecto, Docker retiene capacidades que la inmensa mayoría de servicios web jamás necesitan (como CAPCHOWN, CAPFOWNER o CAPNETRAW).

La práctica estándar consiste en descartar todas las capacidades por defecto y añadir únicamente las estrictamente necesarias:

# Descartar todas las capacidades y retener solo enlaces a puertos de red
docker run -d \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --name api-service \
  mi-imagen:1.0

4. Filtrado de Syscalls mediante Seccomp

El kernel de Linux expone más de 450 llamadas al sistema (syscalls). Docker aplica por defecto un perfil seccomp-bpf que bloquea unas 44 llamadas de alto riesgo (como reboot, ptrace o sys_chroot).

En entornos de alta seguridad, es posible generar perfiles seccomp a medida para restringir el contenedor a las pocas llamadas (habitualmente menos de 70) que su binario realmente necesita durante su ciclo de vida.

5. Sistema de Archivos de Solo Lectura (read-only rootfs)

Salvo directorios de datos específicos explícitamente montados como volúmenes, la raíz del contenedor debe ser de solo lectura. Esto neutraliza de raíz los ataques donde un atacante intenta inyectar binarios maliciosos o scripts en /tmp o /var/tmp:

docker run -d \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  mi-imagen:1.0

Implementación Práctica: Dockerfile Multi-Stage Blindado

El siguiente ejemplo muestra un Dockerfile de producción para una API en Node.js/TypeScript aplicando compilación por etapas (multi-stage build), imagen base mínima, usuario no privilegiado y exclusión de herramientas de desarrollo:

# ==========================================
# ETAPA 1: Compilacion y Construccion (Build)
# ==========================================
FROM node:22-bookworm-slim AS builder

WORKDIR /usr/src/app

# Instalar dependencias aprovechando la cache de capas
COPY package*.json tsconfig.json ./
RUN npm ci --include=dev

# Copiar codigo fuente y compilar TypeScript a JavaScript
COPY src/ ./src
RUN npm run build

# Podar dependencias para dejar unicamente las de produccion
RUN npm prune --omit=dev

# ==========================================
# ETAPA 2: Runtime Seguro de Produccion
# ==========================================
# Empleamos una imagen distroless para Node.js
FROM gcr.io/distroless/nodejs22-debian12:nonroot

WORKDIR /app

# Inyectar variables de entorno de produccion
ENV NODE_ENV=production
ENV PORT=3000

# Copiar unicamente los artefactos necesarios desde la etapa de compilacion
COPY --from=builder /usr/src/app/node_modules ./node_modules
COPY --from=builder /usr/src/app/dist ./dist
COPY --from=builder /usr/src/app/package.json ./package.json

# La imagen distroless ya incluye un usuario no privilegiado por defecto: nonroot (UID 65532)
USER nonroot

EXPOSE 3000

# Punto de entrada determinista sin shell intermedio
CMD ["dist/server.js"]

Ventajas de este Enfoque:

  1. Reducción del tamaño de la imagen: Pasa de ~1.2 GB a menos de 150 MB al eliminar el compilador de TypeScript, los archivos de definición .d.ts y las herramientas del sistema.
  2. Superficie de vulnerabilidad mínima: Al no incluir gestor de paquetes (apt) ni shell (/bin/sh), los escáneres de seguridad arrojan 0 vulnerabilidades críticas.
  3. Imposibilidad de persistencia local: Si una brecha explota el código de Node.js, el atacante no dispone de comandos de consola para pivotar en la red interna.

Ecosistema OCI: De Docker a Podman y Kubernetes

La evolución de los contenedores ha llevado a la estandarización promovida por la Open Container Initiative (OCI), que desacopló la tecnología de la empresa Docker:

  • Especificación de Imagen OCI: Define el formato de manifiestos, capas comprimidas en tar y hashes SHA-256 para que cualquier herramienta pueda construir y leer imágenes universales.
  • Especificación de Runtime OCI: Estandariza la interfaz para interactuar con el kernel. La implementación de referencia es runc.
  • containerd y CRI-O: Demonios de gestión de contenedores optimizados para clústeres de Kubernetes mediante la Container Runtime Interface (CRI), prescindiendo de las capas superfluas del Docker Daemon tradicional.
  • Podman: Una alternativa moderna desarrollada en el ecosistema Red Hat que elimina el demonio central (dockerd). Podman ejecuta los contenedores directamente mediante forks de procesos utilizando la arquitectura daemonless, permitiendo la ejecución rootless de manera nativa sin necesidad de servicios privilegiados corriendo en segundo plano.

Conclusión

Dominar Docker y la tecnología de contenedores en la ingeniería moderna no consiste únicamente en saber escribir comandos como docker run o docker-compose up. Consiste en comprender la arquitectura del kernel que hace posible el aislamiento, respetar la separación estricta entre desarrollo y producción, y aplicar principios de defensa en profundidad desde la concepción del Dockerfile.

Los contenedores son el bloque de construcción fundamental de las arquitecturas en la nube. Complementar este aislamiento con prácticas rigurosas de DevSecOps, Hardening de Sistemas Base y control de accesos federado mediante OAuth 2.1 y OIDC es el único camino para garantizar la resiliencia técnica de una plataforma.

Si tu organización necesita auditar sus imágenes de contenedores, implantar políticas de ejecución rootless y distroless en producción o asegurar pipelines de despliegue en Kubernetes, puedes consultar mis Servicios de Ciberseguridad y Consultoría o ponerte en contacto conmigo a través de mi perfil Sobre mí.