Seguridad en contenedores: Hardening de imágenes y protección en runtime

La cadena de seguridad de contenedores

La seguridad de contenedores comienza con el Base Image y termina con la supervisión en tiempo de ejecución. Cada etapa ofrece superficie de ataque, y cada etapa puede ser asegurada.

Fase de Build: Fortalecer las imágenes

• Base Images mínimos: Distroless o Alpine en lugar de Ubuntu: menos paquetes, menos superficie de ataque.
• Usuario Non-Root: Los contenedores nunca deben ejecutarse como root. Defina un usuario sin privilegios en el Dockerfile.
• Filesystem de solo lectura: Configure el filesystem root como Read-Only y monte los directorios que requieran escritura de forma explícita.
• Sin etiqueta Latest: Fije las versiones del Base Image a digests específicos para builds reproducibles.

Fase de Registry: Escanear imágenes

• Admission Controller: Los Admission Webhooks de Kubernetes pueden bloquear imágenes no firmadas o no escaneadas.
• Image Signing: Cosign o Notary garantizan que solo se desplieguen imágenes verificadas.

Fase de Runtime: Supervisar y restringir

• Security Contexts: Los Security Contexts de Kubernetes imponen Non-Root, filesystems Read-Only y eliminación de Capabilities.
• Pod Security Standards: Los tres niveles Privileged, Baseline y Restricted como políticas a nivel de Namespace.
• Runtime Security: Falco o Sysdig detectan comportamientos sospechosos en contenedores en ejecución.

Conclusión

La seguridad de contenedores no es un producto, sino un proceso. En devRocks implementamos seguridad en cada etapa, desde la revisión del Dockerfile hasta el monitoreo en tiempo de ejecución.