Seguridad de contenedores.

La seguridad de contenedores cubre el ciclo de vida completo de los contenedores OCI (Docker, containerd, CRI-O). En la build, los equipos escanean imágenes en busca de CVE y secretos incrustados, las firman con Sigstore/Cosign y exigen imágenes base mínimas. En la distribución, los registros se protegen con accesos autenticados y verificación de firmas. En runtime, el endurecimiento del host, el aislamiento por namespaces/cgroups, seccomp, AppArmor y sistemas de ficheros de solo lectura reducen la superficie de ataque, mientras que los admission controllers y sensores eBPF aplican políticas y detectan anomalías.

Los contenedores comparten el kernel del host, por lo que un único fallo del kernel o del runtime puede romper el aislamiento. CVE-2019-5736 permitía a una imagen maliciosa sobrescribir el binario runc del host a través de /proc/self/exe, logrando ejecución de código como root en el nodo; se corrigió en runc 1.0-rc7 y Docker 18.09.2. En 2024, "Leaky Vessels" CVE-2024-21626 filtraba un descriptor de fichero interno (fd/7) que apuntaba al directorio de trabajo del host antes de pivot_root, de modo que fijar el cwd del contenedor a /proc/self/fd/7 escapaba del rootfs (corregido en runc 1.1.12). Como la evasión de un pod suele equivaler a comprometer el nodo, importa la defensa en profundidad: eliminar capabilities, ejecutar como no-root, evitar montajes privilegiados y hostPath, mantener runc parcheado y considerar sandboxes más fuertes como gVisor o Kata Containers.

flowchart LR
  A[Build: escanear + firmar imagen] --> B[Registro: autenticar + verificar firma]
  B --> C[Admision: rechazar privilegiados/hostPath]
  C --> D[Runtime: seccomp, AppArmor, no-root, caps eliminadas]
  D --> E[Deteccion: alertas eBPF/Falco]
  D -. fallo kernel/runc .-> X[Evasion del contenedor al host]
  X -. mitigado por .-> F[Sandbox gVisor / Kata]