Seguridad de contenedores: refuerzo de imágenes y protección en tiempo de ejecución

Los contenedores empaquetan el código de una aplicación y sus dependencias en unidades aisladas que comparten el kernel del sistema operativo anfitrión, a diferencia de las máquinas virtuales, que incluyen un sistema operativo invitado completo. Este uso compartido hace que los contenedores sean ligeros y rápidos, pero introduce un modelo de seguridad diferente: una vulnerabilidad de escape de contenedor podría permitir que un atacante saliera del contenedor y accediera directamente al kernel del anfitrión, afectando a todos los demás contenedores. La seguridad de los contenedores se centra en tres capas: la imagen (lo que contiene), el tiempo de ejecución (lo que el contenedor puede hacer mientras se ejecuta) y la plataforma de orquestación (cómo se gestionan los contenedores).

Cada paquete instalado en una imagen de contenedor constituye una posible superficie de ataque. El principio de las imágenes base mínimas consiste en partir de la base más pequeña posible: Alpine Linux (5 MB, con un número mínimo de paquetes), imágenes distroless (imágenes de Google que contienen únicamente el tiempo de ejecución y la aplicación, sin shell ni gestor de paquetes) o scratch (completamente vacía, para binarios compilados estáticamente). Un contenedor sin shell significa que un atacante que consiga ejecutar código no puede ejecutar fácilmente wget, curl u otras herramientas para ampliar su ataque; este principio se denomina defensa mediante una exposición mínima.

De forma predeterminada, los contenedores de Docker se ejecutan como root (UID 0). Si un atacante explota una vulnerabilidad en la aplicación contenida, obtiene privilegios de root dentro del contenedor. Si el contenedor comparte un volumen o tiene montajes del anfitrión, root dentro del contenedor puede equivaler a root en el anfitrión. La solución es sencilla: crear un usuario específico en el Dockerfile y cambiar a él mediante la directiva USER antes del CMD/ENTRYPOINT final. Muchas herramientas de análisis de seguridad de contenedores marcarán como hallazgo cualquier imagen que no tenga un usuario no root.

Los contenedores inmutables son contenedores cuyo sistema de archivos no puede modificarse durante la ejecución. Habilitar --read-only en Docker (o readOnlyRootFilesystem: true en Kubernetes) impide que los atacantes escriban malware en el disco, modifiquen archivos de configuración o instalen herramientas dentro de un contenedor en ejecución. Las aplicaciones que realmente necesitan escribir datos (registros, archivos temporales) pueden montar volúmenes tmpfs específicos para escrituras efímeras. Los contenedores inmutables imponen el principio de que el estado durante la ejecución debe proceder únicamente de la imagen y la configuración, no de modificaciones dentro del contenedor que eludan su canalización de seguridad de CI/CD.

Las herramientas de análisis de imágenes de contenedor analizan los paquetes instalados en una imagen de Docker comparándolos con bases de datos de vulnerabilidades (NVD, CVE) e informan sobre los CVE conocidos. Entre los principales analizadores se encuentran Trivy (Aqua Security, rápido y gratuito), Grype (Anchore), Snyk Container y AWS ECR image scanning. El análisis debe integrarse en el pipeline de CI/CD para que cualquier imagen con CVE críticos o altos haga fallar el pipeline antes de enviarse a un registro. Los analizadores también deben comprobar si hay secretos (claves de API, contraseñas) incrustados accidentalmente en las capas de la imagen.

Un error común y peligroso consiste en incrustar secretos (claves de API, contraseñas de bases de datos, certificados TLS) dentro de las imágenes de Docker, ya sea en variables de entorno incorporadas a la imagen o en archivos añadidos mediante COPY. Estos secretos son visibles para cualquiera que tenga acceso a la imagen mediante docker history o extrayendo sus capas. Aunque una capa posterior elimine el archivo, este permanece en el historial de la imagen. Los secretos deben inyectarse en tiempo de ejecución mediante variables de entorno procedentes de un gestor de secretos, Docker secrets o Kubernetes Secrets montados como volúmenes.

Las herramientas de seguridad en tiempo de ejecución supervisan el comportamiento de los contenedores mientras se ejecutan y generan alertas o bloquean actividades anómalas. Falco (un proyecto de CNCF) se conecta al kernel de Linux mediante eBPF o módulos del kernel para interceptar las llamadas al sistema y compararlas con reglas. Por ejemplo, una regla puede generar una alerta si un contenedor inicia un shell (execve('/bin/sh')), abre una conexión de red en un puerto inesperado o lee /etc/shadow. Estos indicadores de comportamiento suelen señalar un ataque activo, aunque no se haya explotado ningún CVE conocido. Sysdig Secure y Aqua Security ofrecen plataformas comerciales de protección en tiempo de ejecución.

De forma predeterminada, los contenedores de Docker eliminan muchas capacidades de Linux, pero conservan más de las que necesita la mayoría de las aplicaciones. Las capacidades dividen los privilegios de root en unidades independientes (por ejemplo, CAP_NET_ADMIN y CAP_SYS_ADMIN). La práctica recomendada consiste en eliminar todas las capacidades y volver a añadir únicamente las necesarias mediante --cap-drop=ALL --cap-add=NET_BIND_SERVICE. Los perfiles de Seccomp (Secure Computing Mode) especifican mediante una lista de permitidos qué llamadas al sistema puede realizar un contenedor; Docker incluye un perfil de seccomp predeterminado que bloquea aproximadamente 44 llamadas al sistema peligrosas. Los perfiles de seccomp personalizados para aplicaciones específicas pueden restringirlas aún más y bloquear todas las llamadas al sistema que la aplicación nunca utilice legítimamente.

Los registros de contenedores (Docker Hub, AWS ECR, Google Artifact Registry) almacenan y distribuyen imágenes. Para proteger el registro, se debe: habilitar el análisis de vulnerabilidades al realizar el push, restringir el acceso de push únicamente a las cuentas de servicio de CI/CD, habilitar la firma de imágenes mediante Sigstore/Cosign o Docker Content Trust (Notary) para que los entornos de ejecución solo extraigan imágenes firmadas criptográficamente desde fuentes de confianza, y configurar la inmutabilidad de las imágenes para impedir que se sobrescriban las etiquetas (eliminando los ataques de mutación de etiquetas, en los que un atacante reemplaza una etiqueta :latest de confianza por una imagen maliciosa).

Los atacantes que consiguen ejecutar código dentro de un contenedor pueden intentar un escape del contenedor para acceder al host. Entre las técnicas habituales se incluyen: explotar contenedores privilegiados (--privileged proporciona un acceso casi ilimitado al host), abusar de los sockets de Docker expuestos (/var/run/docker.sock montado en un contenedor proporciona acceso completo a la API de Docker, incluida la creación de contenedores privilegiados) y explotar vulnerabilidades del kernel mediante capacidades sin proteger. Defensas: no utilizar el modo privilegiado salvo que sea absolutamente necesario, no montar nunca el socket de Docker en contenedores de aplicaciones, mantener actualizado el kernel del host y utilizar gVisor o Kata Containers para cargas de trabajo que requieran un aislamiento sólido.

El Center for Internet Security (CIS) Docker Benchmark proporciona directrices detalladas de configuración de seguridad para hosts y contenedores de Docker, que abarcan la configuración del daemon, la higiene de las imágenes, los ajustes del tiempo de ejecución de los contenedores y los controles de red. Herramientas como Docker Bench for Security automatizan la comprobación del cumplimiento respecto al CIS benchmark y generan un informe puntuado de elementos aprobados y no aprobados. Ejecutar este benchmark periódicamente e integrarlo en CI/CD garantiza que las desviaciones de la configuración de seguridad se detecten rápidamente. Quienes se preparen para Security+ deben saber que los CIS Benchmarks son una referencia principal para el bastionado de sistemas operativos y plataformas en el contexto del examen.

Ponga a prueba su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que las imágenes base mínimas y los usuarios que no son root reducen la superficie de ataque y el nivel de privilegios de las cargas de trabajo contenerizadas; las herramientas de protección en tiempo de ejecución, como Falco, detectan patrones anómalos de llamadas al sistema indicativos de ataques activos dentro de los contenedores; y que nunca se deben utilizar contenedores privilegiados ni montar el socket de Docker en contenedores de aplicaciones, ya que estas configuraciones permiten escapar del contenedor. A continuación, exploraremos la seguridad de Kubernetes, incluidos RBAC, las políticas de red y los estándares de seguridad de pods.