Protección de las imágenes de Docker

Una imagen de Docker se compone de una pila de capas, que son conjuntos inmutables y de solo lectura de cambios en el sistema de archivos, apilados sobre los que se encuentran debajo. En la base se encuentra el sistema operativo, seguido de los paquetes que necesita para funcionar y, por último, tu propio código en la parte superior. Garantizar la seguridad de las imágenes de Docker implica controlar lo que se incluye en ellas y mantenerlas actualizadas con los parches correspondientes una vez que se han distribuido.

La mayoría de las vulnerabilidades de un contenedor provienen de los paquetes y bibliotecas de código abierto que incluye. Es posible que tu aplicación nunca utilice algunos de ellos, como cURL o un shell, una vez que el contenedor esté en ejecución, por lo que pueden eliminarse de la imagen. Otros, como glibc, son necesarios para que tu aplicación funcione y no pueden eliminarse. El resto de las vulnerabilidades suelen ser consecuencia de errores humanos, como un secreto integrado en una capa o un contenedor que se deja en ejecución con privilegios de root.

En esta entrada se explica de dónde proviene el riesgo en una imagen de Docker, por qué mantener las imágenes protegidas es un problema de « gestión de vulnerabilidades », las tres formas en que las herramientas mantienen actualizadas las imágenes base y cómo Aikido protege y actualiza las imágenes que ya estás ejecutando.

{{cta}}

TL;DR

Para proteger las imágenes de Docker hay que eliminar los paquetes que no se utilizan y aplicar parches a las vulnerabilidades de los que quedan. Al eliminar los paquetes que no se utilizan, solo se eliminan las vulnerabilidades de aquellos elementos que no necesitas. Un paquete vulnerable del que tu aplicación dependa realmente seguirá necesitando un parche, e incluso una imagen minimizada sigue acumulando nuevas vulnerabilidades. Además, adoptar imágenes reforzadas suele implicar migrar a otra distribución y actualizar según el ritmo de otra persona. Aikido proporciona nuevas compilaciones parcheadas de las mismas versiones de imagen base, que se entregan a través de PR. Si has fijado una versión, esto te permite mantenerte en ella, sin cambios que rompan la compatibilidad ni tener que pasar a una nueva imagen.

De dónde proviene el riesgo en una imagen de Docker 

El FROM Esta línea es la primera instrucción de un Dockerfile, en la que se indica el nombre de la imagen base sobre la que se va a crear la imagen. Una DESDE el nodo:24 establece la imagen oficial de Node.js 24 como base, la cual incluye el entorno de ejecución de Node.js y, además, un sistema Debian completo subyacente. Esto incluye un shell, un gestor de paquetes y bibliotecas del sistema, cada uno de los cuales puede contener vulnerabilidades que heredarás antes incluso de escribir una sola línea de tu propio código.

Cada instrucción del Dockerfile añade una capa sobre la anterior, y las capas son inmutables. Si se elimina algo en una capa posterior, solo se oculta; por lo tanto, todo lo que incluye la imagen base permanece en la imagen, independientemente de si tu aplicación lo utiliza o no. Tu aplicación nunca recurre a la mayor parte de lo que incluye la imagen base, pero cada paquete que contiene supone una superficie de ataque.

Por ejemplo, CVE-2023-4911 («Looney Tunables») era una vulnerabilidad de escalada de privilegios locales en el cargador dinámico de glibc, un componente que se encuentra en la capa base de casi todas las imágenes de Linux más habituales. glibc venía incluida en la distribución y cualquier contenedor creado a partir de una base afectada la contenía. 

Diferentes bases, diferente riesgo

No todas las imágenes base incluyen la misma cantidad de componentes. Una imagen de distribución completa incluye mucho más de lo que tu aplicación necesita, incluyendo un shell y un gestor de paquetes que probablemente nunca utilizará. Una variante «slim» elimina parte de eso. Una imagen «distroless» prescinde por completo del shell y del gestor de paquetes y solo conserva lo que necesita el entorno de ejecución. Alpine es pequeña por diseño y, al estar basada en musl en lugar de en glibc, ni siquiera se vio afectada por los «Looney Tunables».

Mantener las imágenes protegidas es un problema de « gestión de vulnerabilidades ».

Una imagen consolidada está limpia el día en que se crea, pero se va desfasando con el tiempo, a medida que se descubren nuevas vulnerabilidades en los paquetes que ya contiene. Mantenerla segura implica tratar la imagen como algo que hay que volver a comprobar ante cada nueva revelación de vulnerabilidades y al que hay que aplicar parches de forma continua. El proceso manual consiste en realizar un seguimiento de las revelaciones de vulnerabilidades en todos los paquetes de cada base y aplicar cada corrección o actualizar la versión manualmente.

Fijar una versión de confianza tiene sentido cuando realmente has probado esa versión y quieres seguir utilizándola, pero aún así debes estar atento a nuevas vulnerabilidades. Una imagen que se fija y se olvida acumulará las vulnerabilidades recién descubiertas. Si esa imagen llega al final de su ciclo de vida y deja de recibir parches del desarrollador original, su lista de fallos conocidos y sin parchear crece. Por ejemplo, Node.js 20 alcanzó el fin de su ciclo de vida el 30 de abril de 2026, por lo que un contenedor que siga fijado en node:20 seguirá funcionando, pero todas las vulnerabilidades reveladas en esa versión desde entonces quedarán sin parchear, sin que se publique ninguna corrección.

El instinto contrario, el de lanzarse siempre a por la última versión, es igual de erróneo. Por ejemplo, la puerta trasera «xz-utils» es una biblioteca de compresión que se incluye en la mayoría de las imágenes base de Linux. Estaba presente en dos versiones recientes concretas, la 5.6.0 y la 5.6.1, y los equipos que seguían utilizando la línea anterior 5.4 nunca estuvieron expuestos al riesgo. La recomendación posterior de la CISA fue rebajar la versión, no actualizarla. 

Lo que sí te mantiene a salvo es tomar decisiones cuidadosas sobre las versiones que utilizas. Piensa en un equipo que fije la versión «debian:bookworm», que deje constancia de que la ha elegido en lugar de la última versión porque la ha probado y es estable, y que la compare con las nuevas vulnerabilidades a medida que se publican. Cuando se da a conocer un nuevo CVE en un paquete de esa imagen, ya saben que lo utilizan y por qué. Eso les permite sopesar el riesgo real frente al coste que supone cambiarlo.

Cómo proteger las imágenes de Docker

Reducir la superficie de ataque

Empieza con una imagen base mínima o preconfigurada. La imagen base determina en gran medida lo que vas a heredar, por lo que esta es la decisión más importante que vas a tomar. (Se trata con más detalle en la siguiente sección)

Utiliza compilaciones en varias etapas para que las herramientas de compilación no se incluyan en la imagen final. La compilación de la imagen suele incorporar un compilador, encabezados de desarrollo y un gestor de paquetes para compilar tu aplicación e instalar sus dependencias. En una compilación de una sola etapa, todo eso queda integrado en la imagen final, aunque la aplicación en ejecución nunca lo utilice. Una compilación en varias etapas produce el artefacto en una etapa temprana y copia solo eso a una etapa final limpia, de modo que no se incluye ninguna de las herramientas de compilación.

Elimina los paquetes que la aplicación en ejecución no necesite. Probablemente no necesites un shell, ya que la mayoría de las aplicaciones inician su proceso directamente y nunca lo invocan en tiempo de ejecución. Las utilidades como cURL o wget son útiles durante la compilación, pero es probable que no las necesites en tiempo de ejecución, ya que tu aplicación realiza sus llamadas de red a través de sus propias bibliotecas. Además, todo lo que cURL haya descargado durante la compilación ya estará integrado en la imagen en el momento de su distribución, por lo que no quedará nada que tenga que descargar. 

Configura los permisos correctamente

Ejecuta el contenedor como usuario no root. Si un atacante consigue ejecutar código en tu aplicación, obtendrá los mismos privilegios con los que se ejecute el contenedor. El uso de un usuario no root reduce el alcance de los daños que podría causar una intrusión.

Utiliza un sistema de archivos raíz de solo lectura. Esto impide que un atacante que ya se encuentre en el interior escriba archivos, instale herramientas o modifique el contenedor en tiempo de ejecución. Cualquier elemento que realmente necesite escribir puede disponer, en su lugar, de un montaje específico en el que se permita la escritura.

Elimina las capacidades de Linux que no utilices. Los contenedores se inician con un conjunto de capacidades del núcleo que la mayoría de las aplicaciones nunca utilizan. CAP_NET_RAW, por ejemplo, permite a un proceso falsificar paquetes de red y está activada por defecto, pero una aplicación web típica nunca la necesita, mientras que un atacante que consiga acceder podría utilizarla para falsificar el tráfico de tu red. Desactiva las que no necesites y vuelve a activar solo las que sí necesites. Desactivar estas capacidades (y volver a activar solo las que necesites) impide que un atacante pueda realizar operaciones con privilegios a las que, de otro modo, tendría acceso.

Mantén los secretos y los archivos sueltos fuera de la imagen

No incluyas secretos en las capas. Un secreto incorporado a través de ARG o COPIAR permanece en el historial de la imagen aunque una capa posterior la elimine, y cualquiera que descargue la imagen puede descomprimir las capas y leerla. Utiliza monturas secretas o Montajes SSH para revelar un secreto en un único paso de compilación sin escribirlo en una capa.

Mantener un secreto fuera de las capas es solo la mitad del trabajo. El contenedor en ejecución sigue necesitando el valor, así que inyecta dicho valor en tiempo de ejecución desde un gestor de secretos específico (Vault, un gestor de secretos en la nube o los secretos de Kubernetes) montado como un archivo o inyectado en el entorno, y renuévalo periódicamente en lugar de almacenar una credencial de larga duración en ningún sitio.

Utiliza un .dockerignore archivo. Controla qué elementos se incluyen en el contexto de compilación desde el principio, por lo que .git, la configuración local y las credenciales sueltas nunca se copian en la imagen mediante un proceso generalizado COPIAR instrucción.

Fíjalo con cuidado

Fija la base con «digest», no con «tag». DESDE el nodo:24 se vuelve a resolver con el tiempo, por lo que dos compilaciones con un mes de diferencia pueden obtener imágenes distintas, y una base comprometida puede colarse sin que nadie se dé cuenta. Fijación por resumen (@sha256:...) hace que la base sea determinista, por lo que se crea exactamente la imagen que se ha probado. Ten en cuenta que, si tu modelo de aplicación de parches distribuye las correcciones en forma de nuevas imágenes, un resumen fijado también retiene esas correcciones. Si, por el contrario, puedes obtener una compilación parcheada de la misma versión que has fijado, evitarás ese problema y mantendrás la seguridad.

No te fíes de «latest». Hay quien da por hecho que se refiere a la versión más reciente y estable, pero en Docker no es más que la etiqueta predeterminada que se aplica a la última imagen publicada sin una etiqueta de versión explícita. Puede que apunte a una imagen más antigua de lo que esperas y puede cambiar entre una compilación y otra.

Comprobar y mantener

Genera un SBOM para cada imagen. Un informe de « lista de materiales de software » es el inventario completo de lo que contiene la imagen, incluyendo todos los paquetes y versiones. Es lo que te permite responder a la pregunta «¿nos afecta?» en el momento en que se da a conocer una nueva vulnerabilidad. 

Firma cada imagen una vez compilada y verifica esa firma antes de que se ejecute mediante un controlador de acceso que rechace cualquier imagen sin firmar. Esa cadena impide que una imagen manipulada o no autorizada llegue al entorno de producción, incluso si alguien lograra acceder a tu registro.

Considera los contenedores en ejecución como inmutables. Una vez desplegada una imagen, no apliques parches ni reconfigures el contenedor en ejecución. Crea una nueva imagen, pruébala y vuelve a desplegarla. De este modo, lo que se está ejecutando siempre coincidirá con lo que has creado, probado y firmado, lo que elimina las desviaciones de configuración y hace que revertir los cambios sea tan sencillo como volver a desplegar la imagen anterior.

Vuelve a comprobar las imágenes de forma continua. Una imagen que se analizó sin problemas la semana pasada puede presentar hoy una vulnerabilidad crítica, ya que cada día se revelan nuevas vulnerabilidades en los paquetes que ya contiene. Por eso, no basta con comprobarlas en el momento de la compilación. 

Tres formas de mantener una imagen base protegida

Mantener una imagen base protegida a medida que se detectan nuevas vulnerabilidades es una tarea continua, y hay tres formas de abordarla.

Hazlo tú mismo

Mantén tu propia base reforzada. Elige una imagen mínima, elimina lo que no necesites y reconstrúyela cada vez que un paquete de la base presente una vulnerabilidad. Mantienes el control total, pero requiere un trabajo y un mantenimiento continuos. Tienes que hacer un seguimiento de las vulnerabilidades en todos los paquetes de la base y aplicar cada corrección manualmente, ya sea mediante backport o actualizando la versión. Multiplica eso por cada base de cada servicio, y te quitará tiempo para todo lo demás que podrías estar desarrollando.

Pasar a la red de distribución renovada de un proveedor

Algunas plataformas ofrecen imágenes reforzadas recompiladas sobre su propia distribución. Migras tus servicios a su base, vuelves a comprobar si hay fallos y, a continuación, te adaptas a su ritmo de lanzamiento, actualizando a un nuevo resumen con cada corrección. Esto conlleva dos inconvenientes. La propia migración puede provocar fallos en cualquier elemento del que dependiera tu aplicación y que el proveedor haya eliminado. Y mantenerte al día con los parches supone caer en la misma trampa de actualización a la que se enfrenta cualquier cambio de dependencia: una nueva versión principal puede modificar las rutas de los paquetes, cambiar los valores por defecto y hacer que un Dockerfile que funcionaba deje de hacerlo. Si fijas un resumen para garantizar la estabilidad, no estarás recibiendo los parches por los que adoptaste la herramienta en primer lugar.

Deja que una herramienta aplique un parche a la versión base que ya estás utilizando

Algunos proveedores te permiten mantener tu versión actual proporcionando compilaciones parcheadas de la misma versión, en lugar de pasar a una nueva imagen. Recibes una nueva compilación de la misma versión con el CVE parcheado, que puedes incorporar revisándola e integrándola como cualquier otro cambio, sin necesidad de editar la imagen que está en ejecución. De esta forma, sigues utilizando la versión que ya has probado y, al mismo tiempo, solucionas la vulnerabilidad.

Cómo protege Aikido las imágenes de Docker

Aikido Security ofrece nuevas versiones parcheadas de las mismas imágenes base que ya utilizas.

Aikido Images es un repositorio con más de 2.000 imágenes de sustitución directa en las que ya se han corregido las vulnerabilidades críticas y de alta gravedad conocidas en el sistema base. Cada una de ellas se recompila, se parchea, se minimiza y se refuerza durante el proceso de compilación, lo que te permite reducir la superficie de ataque y disponer de una configuración predeterminada más segura en el sistema base que ya utilizas.

Mientras que una herramienta de distribución reconstruida distribuye el parche como una nueva imagen a la que hay que migrar, Aikido retrocede la corrección a la versión que has fijado. Toma la corrección de la versión más reciente y la aplica a la versión que ya estás ejecutando, por lo que el cambio es mínimo y la imagen se comporta como siempre. Cuando no es posible realizar una retrocesión limpia, Aikido actualiza o reconstruye el componente en su lugar. El cambio es una sustitución directa que AutoFix propone como solicitud de incorporación de cambios, y cada incorporación procedente de docker.aikido.io incluye una certificación de origen ( SBOM), VEX y SLSA.

Sigue aplicando parches a versiones en las que el proyecto original ya ha dejado de trabajar, incluidas aquellas que han llegado al final de su ciclo de vida, por lo que puedes seguir utilizando una versión anterior sin tener que soportar sus fallos conocidos y sin tener que actualizarla solo para mantener la protección.

Una proporción cada vez mayor de correcciones reales en los paquetes nunca recibe un CVE, por lo que, si tú o tus herramientas solo consultáis la base de datos de CVE, os estáis perdiendo vulnerabilidades. El proceso de aplicación de parches de Aikido se nutre, en parte, de Aikido Intel, que analiza los registros de cambios y el historial de commits del código fuente original para detectar vulnerabilidades que se han corregido discretamente en el código original sin que se les haya asignado un CVE, por lo que la cobertura no se limita a lo que las bases de datos públicas han tenido tiempo de incorporar.

Los paquetes a nivel de aplicación de npm, PyPI, Maven y Go se corrigen in situ a través de las bibliotecas de Aikido, utilizando el mismo enfoque de retroportación que se aplica a tus dependencias. Además, Aikido escaneo de imágenes de contenedores comprueba si hay paquetes del sistema operativo vulnerables, dependencias, entornos de ejecución obsoletos, malware y riesgos relacionados con las licencias en las imágenes base, los comandos de Dockerfile y las cargas de trabajo de Kubernetes, de modo que cualquier hallazgo aparece junto con el código y el contexto de la nube.

El equipo responsable de estas imágenes se incorporó a Aikido tras la adquisición de Root, la empresa creadora de SlimToolkit (antes DockerSlim), una de las herramientas de código abierto más utilizadas para el refuerzo de imágenes. El refuerzo de imágenes fue el punto de partida de este equipo, y la herramienta sigue siendo gratuita y de libre acceso para todo el mundo.

{{walkthrough}}

Preguntas frecuentes