Seguridad en contenedores Docker: guía de hardening 2026

La seguridad de contenedores Docker es el conjunto de controles que impiden que una carga de trabajo contenedorizada se convierta en el punto de apoyo de un atacante sobre el host: escanear imágenes en busca de vulnerabilidades conocidas, ejecutar los procesos con un usuario sin privilegios, eliminar capabilities de Linux, aislar el contenedor del kernel del host y no entregarle nunca las llaves del demonio de Docker. Esta guía es un manual práctico de hardening para 2026, centrado en la capa del contenedor en sí más que en la capa de orquestación que hay por encima.

Un contenedor Docker no es una máquina virtual. Comparte el kernel del host y, por defecto, se ejecuta con una cantidad de privilegios sorprendente. La mayoría de las brechas reales en contenedores se remontan a un puñado de errores: una imagen base vulnerable, un proceso corriendo como root, un socket de Docker montado o un secreto horneado dentro de una capa de la imagen. Cierra esos huecos y eliminarás la mayor parte de la superficie de ataque práctica.

La superficie de ataque de un contenedor Docker

Como los contenedores comparten el kernel del host, la frontera de aislamiento es más fina de lo que muchos equipos suponen. La superficie de ataque relevante se divide en tres partes:

• La imagen: paquetes desactualizados, CVE conocidos, secretos embebidos y capas base sin verificar.
• La configuración de ejecución: capabilities excesivas, sistemas de archivos escribibles, bind mounts del host, modo privilegiado y el socket de Docker.
• El demonio y el host: el demonio de Docker se ejecuta como root por defecto, así que cualquier contenedor capaz de hablar con él controla en la práctica el host completo.

La orquestación añade una capa de riesgo adicional (RBAC, políticas de red, control de admisión) que tratamos en nuestra guía complementaria sobre pentesting de Kubernetes y seguridad del clúster. Este artículo se queda en el nivel del contenedor y la imagen, que es donde tiene que empezar el hardening.

Escaneo de imágenes Docker: la primera línea de defensa

El escaneo de imágenes Docker es la práctica de inspeccionar cada capa de una imagen contra bases de datos de vulnerabilidades antes de que llegue a producción. Conviene tenerlo en dos sitios: el pipeline de CI (romper el build ante nuevos hallazgos HIGH o CRITICAL) y el registro (reescanear de forma continua, porque una imagen base que estaba limpia la semana pasada puede arrastrar un CVE nuevo hoy).

No trates el escaneo como una barrera puntual. Un flujo de trabajo útil se parece a esto:

1. Escanea en cada pull request y bloquea el merge ante CVE críticos sin corregir.
2. Genera un inventario de software (SBOM) en formato CycloneDX o SPDX para poder responder a la pregunta "¿me afecta?" el día que aterrice el próximo Log4Shell.
3. Reescanea de forma programada las imágenes que ya están en el registro, porque los datos de vulnerabilidades cambian aunque la imagen no cambie.
4. Impón una antigüedad máxima de imagen para que nadie despliegue una capa base que lleva meses sin reconstruirse.

Escáneres de vulnerabilidades para Docker: Trivy, Grype y Docker Scout

Un escáner de vulnerabilidades para Docker lee los paquetes instalados, las dependencias de lenguaje y las capas del sistema operativo, y las compara con fuentes como el NVD y los avisos de seguridad de GitHub. Las opciones maduras, tanto de código abierto como de fabricante, son:

• Trivy (Aqua Security): el estándar de facto. Escanea imágenes de contenedor, sistemas de archivos, repositorios Git, IaC e incluso secretos hardcodeados, y corre con comodidad dentro de CI. Es el mismo tipo de escaneo continuo que un CSPM aplica a la configuración cloud, solo que apuntado a tus imágenes.
• Grype (Anchore): encaja limpiamente con Syft para generar SBOM y es fácil de scriptar dentro de pipelines.
• Clair (originalmente de CoreOS, ahora en Quay): escaneo integrado en el registro, buena opción si ya usas Quay.
• Docker Scout: nativo de Docker, muestra los resultados directamente en Docker Desktop y Hub con consejos de remediación.

Elige uno, conéctalo a CI con una política que rompa el build y mantén al día el feed de vulnerabilidades. Un escáner que nadie mira es solo ruido.

Confía en tu imagen base: la cadena de suministro de software

Cada línea FROM es una decisión de cadena de suministro. Una imagen base inflada arrastra cientos de paquetes que nunca usas, cada uno un CVE potencial. Endurece la cadena de suministro con unos cuantos hábitos disciplinados:

• Empieza por lo mínimo. Prefiere variantes distroless, Alpine o slim frente a distribuciones completas. Menos binarios significan una superficie de ataque más pequeña y escaneos más rápidos.
• Fija por digest, no por tag flotante. FROM node:22 puede cambiar bajo tus pies; FROM node:22@sha256:... es reproducible y no se puede sustituir en silencio.
• Prefiere imágenes oficiales o de editor verificado y reconstruye tus propias imágenes base doradas de forma programada.
• Verifica la procedencia. Firma las imágenes con Cosign y Sigstore, y comprueba las firmas en el despliegue para que una imagen sin firmar o manipulada nunca llegue a ejecutarse. Las atestaciones de procedencia SLSA cierran el círculo desde el código fuente hasta el artefacto.

Los incidentes de dependency confusion e imágenes base envenenadas de los últimos años explotaron todos a equipos que confiaban en lo que un registro público les sirviera. La verificación es un seguro barato.

Endurece el Dockerfile

Los flags de ejecución importan, pero muchas victorias se cimentan en tiempo de build.

• Define un USER sin privilegios. Por defecto un contenedor corre como root (UID 0), que en el Docker clásico se mapea a una cuenta poderosa del host. Crea un usuario dedicado y cámbiate a él: RUN adduser -D app && USER app. Ejecuta con un UID por encima de 0.
• Usa builds multietapa para mantener compiladores, gestores de paquetes y secretos de build fuera de la imagen final. Envía solo el artefacto de ejecución.
• Prefiere COPY frente a ADD y añade un .dockerignore estricto para no filtrar nunca .git, .env o credenciales locales dentro de una capa.
• No hornees nunca secretos en las capas. Un secreto escrito en una capa y borrado en la siguiente sigue vivo en el historial de la imagen. Usa los secret mounts de BuildKit (RUN --mount=type=secret) para credenciales en tiempo de build. Los secretos hardcodeados son una de las malas configuraciones cloud más peligrosas que encontramos en auditorías, y las imágenes no son una excepción.

Hardening en tiempo de ejecución

Elimina capabilities de Linux

Docker concede un conjunto de capabilities de Linux por defecto que la mayoría de las cargas de trabajo nunca necesita, como CAP_NET_RAW o CAP_SETUID. Elimínalas todas y vuelve a añadir solo lo imprescindible:

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE myimage

Y no recurras jamás a --privileged, que desactiva de golpe casi todos los controles de aislamiento.

Sistema de archivos raíz de solo lectura

Ejecuta el contenedor con un sistema de archivos inmutable para que un atacante no pueda dejar herramientas ni establecer persistencia:

docker run --read-only --tmpfs /tmp myimage

Monta un pequeño tmpfs escribible solo donde la aplicación necesite de verdad espacio temporal.

Modo rootless

El Docker rootless (y Podman) ejecuta el demonio y los contenedores con un usuario sin privilegios. Si se produce un escape de contenedor, el atacante aterriza como usuario normal en lugar de como root del host, lo que reduce muchísimo el radio de impacto. Hay compromisos en torno a la red y a algunos drivers de almacenamiento, pero para la mayoría de las cargas de aplicación el modo rootless ya está listo para producción.

Perfiles seccomp y AppArmor

Docker incluye un perfil seccomp por defecto que bloquea alrededor de 40 llamadas al sistema peligrosas. Déjalo activado y aprieta más con un perfil personalizado para cargas de alto valor. Superpón encima un perfil de control de acceso obligatorio (AppArmor en Debian y Ubuntu, SELinux en RHEL). Lo único que nunca hay que hacer es --security-opt seccomp=unconfined, que tira por completo el filtro de syscalls.

Nunca montes el socket de Docker

Montar /var/run/docker.sock dentro de un contenedor equivale a darle a ese contenedor root sobre el host: puede lanzar un nuevo contenedor privilegiado y escapar en segundos. Los runners de CI y los agentes de monitorización lo hacen con demasiada frecuencia. Entre las opciones más seguras están el Docker rootless, un runtime endurecido como Sysbox, un proxy de socket acotado que solo exponga las llamadas de la API que realmente necesitas, o constructores de imágenes sin socket como Kaniko y Buildah.

Gestiona los secretos fuera de la imagen

Los secretos pertenecen al tiempo de ejecución, inyectados por tu orquestador o por una bóveda, nunca dentro de la imagen. Si los horneas, persisten en el historial de capas para cualquiera que descargue la imagen. Usa los secret mounts de BuildKit durante los builds y un gestor de secretos (HashiCorp Vault, AWS Secrets Manager, el almacén de Secrets de Kubernetes) en ejecución. Es la misma disciplina de postura que se extiende hacia arriba en la pila: la deriva de infraestructura la caza el CSPM, la exposición SaaS la cubre el SSPM y la gestión de postura SaaS, y el contenedor no es más que la siguiente capa hacia abajo.

Dónde encaja el hardening de contenedores

El hardening de contenedores es una capa de una postura de seguridad cloud más amplia, no la totalidad. Los controles anteriores cierran las vías de escape más comunes, pero una validación externa sigue mereciendo la pena, porque un tester habilidoso encadena una imagen base débil, un mount con permisos excesivos y un token filtrado en una ruta de ataque que ningún escáner marca por separado. Eso es exactamente lo que hace nuestro servicio de auditoría cloud: valida cuáles de tus hallazgos de contenedor y cloud son genuinamente explotables.

Preguntas frecuentes

¿La seguridad de contenedores Docker es distinta de la seguridad de Kubernetes?

Sí, y la distinción importa. La seguridad de Docker trata del contenedor individual y su imagen: capabilities, el usuario con el que se ejecuta, el sistema de archivos y las capas base. La seguridad de Kubernetes añade la capa de orquestación por encima: RBAC, controladores de admisión, políticas de red y gestión de secretos a lo largo de un clúster. Necesitas ambas. Endurece primero el contenedor y luego asegura cómo el clúster los programa y los conecta.

¿Qué escáner de vulnerabilidades para Docker debería elegir?

Para la mayoría de los equipos, Trivy es la opción pragmática por defecto: es de código abierto, rápido y escanea imágenes, sistemas de archivos, IaC y secretos desde un único binario. Grype es una alternativa excelente, sobre todo emparejado con Syft para los SBOM. Docker Scout resulta cómodo si vives en Docker Desktop y Hub. El escáner importa menos que conectarlo a CI con una política que rompa el build ante vulnerabilidades críticas sin corregir.

¿El modo rootless rompe los contenedores existentes?

Normalmente no en las cargas de aplicación. La mayoría de los contenedores que ejecutan un servicio web, un worker o una API funcionan bien en rootless. Puedes encontrar fricción con cargas que necesitan puertos bajos, drivers de almacenamiento concretos o red a nivel de host, pero son la excepción. Prueba en staging y trata el rootless como el valor por defecto en lugar de como un caso especial.

¿Cómo se filtran los secretos dentro de las imágenes Docker?

El error clásico es copiar un fichero .env o una clave de API dentro de una capa, o ejecutar un comando de build con un secreto como argumento. Aunque una capa posterior borre el fichero, la capa anterior sigue conteniéndolo y viaja con la imagen. Usa los secret mounts de BuildKit en tiempo de build e inyecta los secretos de ejecución a través de tu orquestador o de una bóveda, nunca mediante COPY ni una variable de entorno horneada en la imagen.

¿Basta con el escaneo de imágenes por sí solo?

No. El escaneo encuentra CVE conocidos en los paquetes, algo esencial pero parcial. No arregla un contenedor corriendo como root, un socket de Docker montado, un bind mount demasiado amplio o una credencial filtrada. El escaneo es un control entre varios: combínalo con un usuario sin privilegios, capabilities eliminadas, un sistema de archivos de solo lectura, seccomp y una gestión disciplinada de los secretos.

Seguridad de contenedores con Secra

En Secra endurecemos y probamos las cargas contenedorizadas de principio a fin: pipelines de escaneo de imágenes, revisión de Dockerfile y ejecución, verificación de la cadena de suministro y seguridad de la orquestación. Si quieres una evaluación externa de tu stack de Docker y Kubernetes, o ayuda para construir pipelines de build seguros, escríbenos a través de contacto y te devolveremos una primera valoración.