Skip to main content
Snyk Blog

In this article

Toma medidas para mejorar la seguridad de tus imágenes de Docker

Escrito por
Headshot of Brian Vermeer

Brian Vermeer

William Henry

Docker report DARK

17 de abril de 2019

0 minutos de lectura

Te damos la bienvenida al informe sobre seguridad de Docker: Desplazar la seguridad de Docker a la izquierda. Este informe se divide en varias publicaciones:

También puedes descargar nuestro atractivo informe en PDF, elaborado artesanalmente, que reúne toda esta información y más en un solo lugar:

También puedes descargar nuestro atractivo informe en PDF, elaborado artesanalmente, que reúne toda esta información y más en un solo lugar.

Cómo elegir la imagen base adecuada

Una forma popular de abordar este desafío es contar con dos tipos de imágenes base: una para el desarrollo y las pruebas unitarias, y otra para las pruebas de las etapas posteriores y la producción. Para estas últimas, la imagen no necesita herramientas de compilación como compiladores (por ejemplo, Javac), sistemas de compilación (como Maven) ni herramientas de depuración. De hecho, en producción, es posible que la imagen ni siquiera necesite Bash.

Observamos diferencias notables entre las imágenes de sistemas operativos básicos y sus distintas variantes. En la mayoría de los casos, no hace falta una imagen de sistema operativo completa. Las herramientas para crear imágenes, como Buildah, permiten crearlas desde cero e instalar solo los paquetes necesarios y sus dependencias. Esto reduce considerablemente la superficie de ataque de las imágenes. Piensa en una imagen de una aplicación de Python que solo incluya el paquete de Python, sus dependencias y la aplicación.

Otra ventaja de Buildah es que no requiere el proceso del daemon de Docker. Esto es importante en plataformas de implementación de contenedores a gran escala que reutilizan recursos para crear imágenes de contenedor. El daemon de Docker es un proceso privilegiado con un socket abierto para comunicarse con él. Si alguien explota el daemon de Docker, el nodo queda comprometido y, a menudo, eso puede comprometer todo un clúster. Aislar explícitamente los nodos de compilación o usar una herramienta como Buildah elimina la necesidad del daemon de Docker.

Elegir una versión reducida u otra implementación de una distribución de Linux puede ayudar a reducir la cantidad de vulnerabilidades. Al analizar la imagen base de Alpine, una imagen mínima de Docker de 5 MB basada en Alpine Linux, no encontramos vulnerabilidades conocidas. Sin embargo, esto se debe principalmente a que el proyecto Alpine no mantiene un programa de avisos de seguridad; por lo tanto, si hay vulnerabilidades, no existe un aviso oficial donde comunicarlas. Aun así, Alpine es un buen ejemplo de una imagen base muy minimalista y reducida sobre la que se puede construir.

Aunque no detectamos vulnerabilidades en la versión de la imagen de Alpine que probamos, eso no significa necesariamente que esté libre de problemas de seguridad. Alpine Linux gestiona las vulnerabilidades de forma distinta a las otras distribuciones principales, que suelen aplicar conjuntos de parches a versiones anteriores. En Alpine, prefieren ciclos de publicación rápidos para sus imágenes, y cada versión incluye una actualización de las bibliotecas del sistema.

Gráfico de barras titulado «Vulnerabilidades en imágenes de SO»: Debian 55, Debian stretch-slim 42, Ubuntu 31, CentOS 1, Fedora 0 y Alpine 0.

Como puedes ver en el gráfico anterior, cambiar la imagen base en el Dockerfile o simplemente usar otra etiqueta de una imagen estándar puede marcar una gran diferencia.

Al crear tu propia imagen a partir de un Dockerfile, asegúrate de no depender de imágenes más grandes de lo necesario. Así reduces el tamaño de la imagen y también la cantidad de vulnerabilidades que pueden introducirse a través de las dependencias.

Gráfico de barras titulado “Vulnerabilidades en imágenes de Node.js”, que muestra 567 para node:latest, 65 para node:10-slim y 0 para node:10-alpine.

Según los análisis realizados por usuarios de Snyk, descubrimos que el 44 % de los análisis de imágenes de Docker detectaron vulnerabilidades conocidas para las que había imágenes base más nuevas y seguras disponibles. Este consejo de remediación es exclusivo de Snyk. Los desarrolladores pueden tomar medidas para actualizar sus imágenes de Docker. Automatizar la búsqueda de imágenes base más nuevas o mejores y generar alertas al respecto puede considerarse una buena práctica.

Usa compilaciones de varias etapas

Las compilaciones de varias etapas están disponibles a partir de Docker 17.05. Están diseñadas para crear un Dockerfile optimizado que sea fácil de leer y mantener.

Con una compilación de varias etapas, puedes usar varias imágenes y copiar de forma selectiva solo los artefactos necesarios de una imagen específica. Puedes usar varias instrucciones FROM en tu Dockerfile y una imagen base distinta para cada FROM, copiando los artefactos de una etapa a la siguiente. Puedes dejar atrás los artefactos que no necesitas y obtener una imagen final concisa.

Este método para crear una imagen pequeña no solo reduce considerablemente la complejidad, sino también la posibilidad de incluir artefactos vulnerables en ella. En lugar de usar imágenes basadas en otras imágenes, que a su vez se basan en otras, las compilaciones de varias etapas te permiten seleccionar los artefactos que necesitas sin heredar las vulnerabilidades de las imágenes base de las que dependes. Encontrarás más información sobre cómo crear compilaciones de varias etapas en la documentación de Docker.

Como mencionamos antes en el informe, otra opción es usar herramientas como Buildah para crear imágenes mínimas de producción con solo los paquetes necesarios para ejecutar tu aplicación. Para obtener más información sobre Buildah, consulta Buildah.io y Podman y Buildah para usuarios de Docker.

Reconstruir imágenes

Todas las imágenes de Docker se crean a partir de un Dockerfile. Los Dockerfiles de las imágenes de Docker Hub están disponibles públicamente en GitHub. Un Dockerfile contiene un conjunto de instrucciones que permite automatizar los pasos que normalmente seguirías de forma manual para crear una imagen. Además, puedes importar algunas bibliotecas e instalar software personalizado. Todo esto se indica en el Dockerfile. En el informe Estado de la seguridad del código abierto de 2019, descubrimos que un simple proceso de reconstrucción habría podido resolver el 20 % de las vulnerabilidades de las imágenes de Docker.

Crear una imagen es, básicamente, obtener una instantánea de ella en ese momento. Si dependes de una imagen base sin una etiqueta fija, la imagen base puede cambiar cada vez que vuelvas a compilarla. Si instalas paquetes con un administrador de paquetes, la imagen también puede cambiar al reconstruirla.

Un Dockerfile que contenga lo siguiente puede generar un binario distinto con cada reconstrucción.FROM ubuntu:latestRUN apt-get -y update && apt-get install -y python

Debes reconstruir todas las imágenes de Docker con regularidad para evitar que contengan vulnerabilidades conocidas que ya se hayan corregido. Al reconstruir, usa la opción sin caché --no-cache para evitar que se use la caché y garantizar una descarga actualizada.

Por ejemplo:docker build --no-cache -t myImage:myTag myPath/

En resumen, sigue estas prácticas recomendadas al reconstruir tu imagen:

  • Cada contenedor debe tener una sola responsabilidad.

  • Los contenedores deben ser inmutables, ligeros y rápidos.

  • No guardes datos en el contenedor; usa un almacén de datos compartido.

  • Los contenedores deben ser fáciles de destruir y reconstruir.

  • Usa una imagen base pequeña, como Linux Alpine. è Las imágenes más pequeñas son más fáciles de distribuir.

  • Evita instalar paquetes innecesarios.

  • Así mantendrás la imagen ordenada, limpia y segura.

  • Evita usar la caché durante la compilación.

  • Analiza automáticamente tu imagen antes de implementarla con una herramienta como el análisis de contenedores de Snyk para evitar que se envíen contenedores vulnerables a producción.

  • Analiza tus imágenes a diario para detectar vulnerabilidades, tanto durante el desarrollo como en producción. En función de los resultados, automatiza la reconstrucción de las imágenes si es necesario.

Analizar imágenes durante el desarrollo

Crear una imagen a partir de un Dockerfile e incluso reconstruirla puede introducir nuevas vulnerabilidades en tu sistema. Antes vimos que el 68 % de los usuarios cree que los desarrolladores tienen una responsabilidad considerable en la seguridad de los contenedores. Analizar tus imágenes de Docker durante el desarrollo debería ser parte de tu flujo de trabajo para detectar vulnerabilidades lo antes posible.

Para desplazar la seguridad a la izquierda, lo ideal es que los desarrolladores puedan analizar un Dockerfile y sus imágenes desde su equipo local antes de confirmarlos en un repositorio o una canalización de compilación.

Esto no significa que debas reemplazar los análisis de la canalización de CI por análisis locales, sino que conviene analizar en todas las etapas del desarrollo y, de preferencia, automatizar los análisis. Considera realizar análisis automatizados durante la compilación, antes de enviar la imagen a un registro y antes de implementarla en un entorno de producción. Evitar que una imagen llegue a un registro o al sistema de producción porque el análisis automatizado detectó nuevas vulnerabilidades debería considerarse una práctica recomendada.

La nueva función de gestión de vulnerabilidades en contenedores de Snyk analiza imágenes de Docker al extraer sus capas e inspeccionar la información de los manifiestos del administrador de paquetes. Después comparamos cada paquete del sistema operativo instalado en la imagen con nuestra base de datos de vulnerabilidades de Docker. Además, es fundamental analizar los binarios clave instalados en las imágenes. Snyk también permite analizar binarios clave que suelen instalarse mediante métodos distintos al administrador de paquetes del sistema operativo (dpkg, RPM y APK), por ejemplo, con un comando RUN.

Al proporcionar a los desarrolladores herramientas para analizar Dockerfiles e imágenes en sus equipos locales durante el desarrollo, se crea una capa adicional de protección y pueden contribuir activamente a que el sistema sea más seguro en general.

Analizar contenedores durante la producción

Resulta que el 91 % de los encuestados no analiza sus imágenes de Docker en producción. Revisar activamente tus contenedores puede ahorrarte muchos problemas cuando se descubre una nueva vulnerabilidad y tu sistema de producción puede estar en riesgo.

Puedes analizar periódicamente, por ejemplo a diario, tus imágenes de Docker con las funciones de monitoreo de contenedores de Snyk. Snyk crea una instantánea de las dependencias de la imagen para monitorearlas de forma continua.

Además, también deberías activar el monitoreo en tiempo de ejecución. Analizar los módulos y paquetes que no se usan durante la ejecución te permite saber cómo reducir el tamaño de las imágenes. Eliminar los componentes que no se usan evita que se incorporen vulnerabilidades innecesarias a las bibliotecas del sistema y de la aplicación. También facilita el mantenimiento de la imagen.

Sigue leyendo:

Descarga el informe ahora!

Publicado en:
Seguridad del contenedor