Si sigues ejecutando contenedores como root o usando la imagen base ubuntu:latest en producción, estás a un solo CVE de una intrusión completa. Los contenedores no son sandboxes mágicos; una mala configuración es una autopista hacia el kernel del host. Aquí tienes tres pasos tácticos para endurecer tu pipeline hoy mismo.
Conceptos Clave:
- Multi-stage Builds: No lleves herramientas de compilación (apt, npm, go) al entorno final. Mantén la imagen final lo más pequeña posible.
- Usuario no privilegiado: Si el proceso dentro del contenedor es comprometido, que el atacante no tenga permisos de escritura en directorios críticos.
- Superficie de ataque mínima: Elimina shells y paquetes innecesarios.
- Ejemplo Práctico (Dockerfile optimizado):
# Etapa 1: Build
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# Etapa 2: Runtime (Distroless es tu mejor aliado)
FROM gcr.io/distroless/nodejs20-debian12
WORKDIR /app
# Crear usuario sin privilegios
USER 1000:1000
COPY --from=build /app/dist ./dist
# Solo exponemos el puerto necesario
EXPOSE 3000
CMD ["dist/server.js"]Checklist de Mitigación:
- .dockerignore: ¿Excluyes .git, node_modules locales, .env y archivos de test? Si no, estás filtrando información sensible (secrets, código fuente) en cada build.
- Drop Capabilities: En tiempo de ejecución, aplica –cap-drop=all –cap-add=NET_BIND_SERVICE. No entregues permisos que tu aplicación no requiere explícitamente.
- Read-Only Root FS: Ejecuta contenedores con readOnlyRootFilesystem: true. Si el atacante no puede escribir en el sistema de archivos, el malware no puede persistir tras un reinicio.
- Escaneo en CI/CD: Integra herramientas como Trivy o Grype. Si el scan detecta una CVE ‘High’ o ‘Critical’, el pipeline debe romperse automáticamente (–exit-code 1). El despliegue se detiene antes de que el código llegue a producción.
Recomendación de seguridad
Si trabajas con AWS, deja de inyectar credenciales estáticas o variables de entorno con keys. Usa IAM Roles for Service Accounts (IRSA) para asignar permisos temporales y acotados mediante tokens rotativos. Es la diferencia entre un incidente contenido y un desastre por «Access Key leak» en tu repositorio.
¿Tu equipo tiene el pipeline configurado para fallar automáticamente ante una CVE crítica o todavía permiten despliegues «por urgencia»? Los leo en los comentarios.
0 comentarios