🔧 Solucionando Vulnerabilidades en Imágenes Docker
Ahora que hemos escaneado nuestra imagen vulnerable con Docker Scout, vamos a corregir los problemas de seguridad identificados.
1️⃣ Analizando el Dockerfile Vulnerable
Examinemos las vulnerabilidades en nuestro Dockerfile.vulnerable:
# Etapa de construcción
# Usando Node.js 12.22.0 que tiene CVE-2021-22883 (vulnerabilidades de OpenSSL)
FROM node:12.22.0-alpine as build
# Etapa de producción
# Usando Nginx 1.14.0 que tiene CVE-2019-9516 (vulnerabilidad DoS en HTTP/2)
FROM nginx:1.14.0-alpine
# Instalar paquetes adicionales - usando una versión vulnerable de curl
# CVE-2018-1000120 en curl 7.60.0
RUN apk add --no-cache curl opensslDocker Scout identificó varias vulnerabilidades:
- Node.js 12.22.0: Contiene vulnerabilidades de OpenSSL (CVE-2021-22883).
- Nginx 1.14.0: Contiene una vulnerabilidad de DoS en HTTP/2 (CVE-2019-9516).
- curl: Contiene la vulnerabilidad CVE-2018-1000120.
2️⃣ Creando un Dockerfile Corregido
Creemos una versión corregida de nuestro Dockerfile:
cat << 'EOF' > Dockerfile.fixed
# Etapa de construcción
# Actualizado a Node.js 20 (última LTS) para corregir vulnerabilidades
FROM node:20-alpine as build
WORKDIR /app
ENV DISABLE_ESLINT_PLUGIN=true
# Copiar archivos de paquetes e instalar dependencias
COPY package*.json ./
RUN npm install --no-package-lock
# Copiar el resto del código de la aplicación
COPY . .
RUN npm run build
# Etapa de producción
# Usando una versión de Alpine más reciente con menos vulnerabilidades
FROM nginx:stable-alpine
# Copiar la salida de la construcción para reemplazar el contenido por defecto de nginx
COPY --from=build /app/build /usr/share/nginx/html
# Copiar configuración de nginx
COPY nginx.conf /etc/nginx/conf.d/default.conf
# Actualizar paquetes antes de instalar para obtener los últimos parches de seguridad
RUN apk update && \
apk upgrade && \
apk add --no-cache curl openssl
# Exponer puerto
EXPOSE 80
# Iniciar nginx con un usuario no-root para mejor seguridad
# Crear un usuario no-root para ejecutar nginx
RUN adduser -D -H -u 1000 -s /sbin/nologin nginx-user && \
chown -R nginx-user:nginx-user /var/cache/nginx /etc/nginx/conf.d
USER nginx-user
CMD ["nginx", "-g", "daemon off;"]
EOFCorrecciones clave:
- Se actualizó Node.js de 12.22.0 a 20 (última LTS).
- Se actualizó Nginx de 1.14.0 a stable-alpine (base más reciente).
- Uso de
apk update && apk upgradepara asegurar que todos los paquetes estén en sus últimas versiones disponibles. - Se agregó endurecimiento (hardening) de seguridad ejecutando Nginx como un usuario no-root.
3️⃣ Construir y Escanear la Imagen Corregida
Construye la imagen usando el Dockerfile corregido:
docker build -t $DOCKER_USERNAME/rent-a-room:fixed -f Dockerfile.fixed .Ejecuta otro escaneo de Docker Scout para confirmar que los problemas principales se han corregido:
docker scout cves $DOCKER_USERNAME/rent-a-room:fixedEs posible que aún veas algunas vulnerabilidades en los resultados del escaneo. Esto es común en la seguridad de contenedores; incluso los últimos paquetes disponibles en un repositorio pueden tener vulnerabilidades conocidas que aún no han sido parcheadas.
Entendiendo las vulnerabilidades restantes
Incluso en nuestra imagen "corregida", podrías ver vulnerabilidades en:
- expat: Una dependencia de la imagen de Nginx Alpine.
- curl: La última versión disponible en el repositorio de Alpine.
- musl: Una librería principal de Alpine.
- busybox: Un paquete de utilidades principal de Alpine.
Estas vulnerabilidades representan la realidad de la seguridad de contenedores; a menudo hay un equilibrio entre:
- Usar los últimos paquetes disponibles.
- Esperar a que los parches de seguridad estén disponibles en el repositorio.
- Aceptar cierto nivel de riesgo para vulnerabilidades no críticas.
4️⃣ Comparar los Resultados
Comparemos los resultados del escaneo entre la imagen vulnerable y la corregida:
docker scout compare $DOCKER_USERNAME/rent-a-room:vulnerable --to $DOCKER_USERNAME/rent-a-room:fixed
Esto te mostrará una comparación lado a lado de las vulnerabilidades que fueron remediadas.
5️⃣ Evaluación de Riesgos y Estrategias de Mitigación
Cuando manejes las vulnerabilidades restantes, considera estas estrategias:
- Evaluar la severidad y explotabilidad: Las vulnerabilidades críticas en paquetes expuestos necesitan atención inmediata.
- Usar supresión de vulnerabilidades: Para vulnerabilidades que has evaluado como de bajo riesgo.
- Considerar imágenes base alternativas: Algunas distribuciones parchean vulnerabilidades más rápido que otras.
- Implementar defensa en profundidad: Usa políticas de red, protección en tiempo de ejecución y principios de mínimo privilegio.
6️⃣ Mejores Prácticas para Dockerfiles Seguros
| Mejor Práctica | Descripción |
|---|---|
| Usar Imágenes Oficiales | Siempre usa imágenes oficiales de Docker como imágenes base. |
| Usar Etiquetas Específicas | Evita la etiqueta latest; usa etiquetas de versión específicas. |
| Mantener Imágenes Base Actualizadas | Actualiza regularmente las imágenes base para incluir parches de seguridad. |
| Minimizar Capas de la Imagen | Combina comandos RUN para reducir las capas y la superficie de ataque. |
| Usar Construcciones Multi-etapa | Separa los entornos de construcción y de ejecución. |
| Especificar Versiones de Paquetes | Fija (pin) las versiones de los paquetes para evitar actualizaciones inesperadas. |
| Escanear Imágenes Regularmente | Integra Docker Scout en tu pipeline de CI/CD. |
📌 Próximas Pasos
Ahora que nuestra imagen es segura, ¡vamos a automatizar el escaneo de vulnerabilidades en AWS CodePipeline!
Pasa a la siguiente sección para la integración de CI/CD. 🚀
