Ejecutar procesos dentro de un contenedor como usuario ‘root’ es una de las prácticas más riesgosas en entornos de producción. Si un atacante logra explotar una vulnerabilidad y escapar del contenedor (container breakout), obtendrá privilegios de root directamente en el host subyacente. La seguridad en contenedores debe basarse en el principio de menor privilegio, limitando el impacto ante una posible intrusión.
Ejemplo Práctico: Dockerfile Hardening
Configuración Vulnerable:
Por defecto, Docker ejecuta todo como root.
FROM alpine:latest
RUN apk add --no-cache nginx
CMD ["nginx", "-g", "daemon off;"]Configuración Segura:
Creamos un usuario y grupo específicos para el servicio, evitando permisos de superusuario.
FROM alpine:latest
RUN apk add --no-cache nginx && \
addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
CMD ["nginx", "-g", "daemon off;"]Estrategias de Mitigación y Buenas Prácticas
Directiva USER: Define siempre un usuario sin privilegios en el Dockerfile. Nunca operes como root a menos que sea estrictamente necesario para la configuración inicial.
- Capabilities del Kernel: Reduce la superficie de ataque limitando las capacidades del kernel. Ejecuta tus contenedores con –cap-drop=ALL y agrega solo las necesarias (ej. –cap-add=NET_BIND_SERVICE).
- Filesystem Read-only: Ejecuta el contenedor con la bandera –read-only para prevenir modificaciones maliciosas en el sistema de archivos raíz, montando volúmenes temporales (tmpfs) solo donde sea necesario.
- User Namespaces: Habilita userns-remap en el daemon de Docker. Esto permite mapear el usuario root del contenedor a un usuario no privilegiado en el host, mitigando drásticamente el riesgo de un escape exitoso.
¿Estás implementando un perfil de seguridad estricto en tus entornos de producción o mantienes las configuraciones por defecto? ¿Qué herramienta utilizas actualmente para escanear tus imágenes en busca de vulnerabilidades (ej. Trivy, Clair, Grype)? Cuéntanos tu flujo de trabajo.
0 comentarios