Los contenedores no son máquinas virtuales. Ejecutar aplicaciones como root es un error de configuración que en entornos de producción suele ser la puerta de entrada para un container escape. Si tu proceso dentro del contenedor es root, cualquier vulnerabilidad en tu código o librerías da al atacante privilegios elevados sobre tu host.
Como especialistas en seguridad, debemos aplicar el principio de menor privilegio desde el Dockerfile.
Checklist de Seguridad para Contenedores
- Usuario no privilegiado: Nunca uses root. Define un usuario específico en tu Dockerfile para ejecutar la aplicación.
- Imágenes minimalistas: Usa alpine o distroless. Menos paquetes instalados significa una superficie de ataque mucho menor.
- Versiones fijas: Olvida el tag :latest. Usa versiones específicas o hashes de imagen (sha256:abcd…) para asegurar la inmutabilidad y evitar ataques de supply chain.
- Filesystem de solo lectura: Si tu app no necesita escribir en disco, usa el flag –read-only. Esto detiene a la mayoría de los exploits que intentan descargar malware en tiempo de ejecución.
- Capabilities reducidas: Por defecto, Docker otorga capacidades del kernel que probablemente no necesites.
Ejemplo Práctico
En lugar de un docker run básico, endurece tu ejecución:
–cap-drop ALL: Elimina todos los privilegios del kernel.
–cap-add NET_BIND_SERVICE: Solo permite al contenedor enlazar puertos privilegiados (si es necesario).
–no-new-privileges: Previene que el contenedor gane más privilegios mediante setuid.
Recomendación para tu CI/CD
El hardening no es manual. Integra herramientas como Trivy o el módulo de Vulnerability Detection de Wazuh en tu pipeline. No permitas que una imagen con vulnerabilidades críticas llegue a tu registro o cluster. Si la imagen es vulnerable al momento del build, el proceso debe fallar automáticamente.
¿Tu pipeline actual bloquea el despliegue cuando detecta una vulnerabilidad crítica o simplemente envía un aviso? Te leo en los comentarios.
0 comentarios