Las 5 mejores prácticas de seguridad de Docker para proteger tus aplicaciones

La seguridad de Docker comienza antes de que un contenedor se ejecute. Tu imagen puede incluir paquetes vulnerables, tu contenedor puede ejecutarse con más privilegios de los necesarios, o tu socket de Docker puede darle a un atacante un camino directo al host.

Estas cinco prácticas de seguridad de Docker se centran en los controles que marcan la mayor diferencia en el día a día: imágenes confiables, superficies de ejecución pequeñas, procesos no root, acceso de red limitado y un daemon protegido.

1. Escanea regularmente las imágenes de Docker en busca de vulnerabilidades

Uno de los pasos más críticos en la seguridad de Docker es asegurarse de que las imágenes de contenedor que despliegues estén libres de vulnerabilidades conocidas. Las imágenes son los bloques de construcción de tus contenedores, y si una imagen contiene código malicioso o software desactualizado y vulnerable, tu aplicación hereda esos riesgos.

Por qué es crucial escanear imágenes

Identificar exploits conocidos: Los escáneres de imágenes pueden detectar vulnerabilidades conocidas públicamente (CVE) en los paquetes del sistema operativo y las dependencias de la aplicación dentro de tus imágenes.
Prevenir ataques a la cadena de suministro: Asegúrate de que las imágenes base que utilizas no hayan sido manipuladas ni contengan cargas maliciosas.
Mantener el cumplimiento normativo: Muchos marcos regulatorios requieren escaneos regulares de vulnerabilidades para los componentes de software.

Herramientas y técnicas

Varias herramientas pueden ayudarte a escanear tus imágenes de Docker:

Docker Scout: La herramienta de análisis de imágenes de Docker, disponible a través de productos de Docker y flujos de trabajo de CLI según tu configuración.
Trivy: Un escáner de código abierto y fácil de usar que encuentra vulnerabilidades en imágenes de contenedores, repositorios de Git y más.
Clair: Otra herramienta de análisis estático de vulnerabilidades de código abierto para contenedores.
CLI de Trivy:
```
trivy image tu-imagen-docker:tag
```

Mejor práctica: Integra el escaneo de imágenes en tu pipeline de Integración Continua/Despliegue Continuo (CI/CD). Esto asegura que las imágenes se escaneen antes de ser desplegadas en producción, evitando que imágenes vulnerables lleguen a entornos en vivo.

2. Minimiza la superficie de ataque del contenedor usando imágenes base mínimas

El principio de mínimo privilegio se extiende a las imágenes de contenedor. Cuanto más pequeña y enfocada sea tu imagen base, menos vulnerabilidades potenciales contendrá y más difícil será para un atacante explotarla.

Por qué importan las imágenes mínimas

Número reducido de vulnerabilidades: Menos paquetes significan menos puntos de entrada potenciales para los atacantes.
Huella más pequeña: Las imágenes mínimas permiten descargas e implementaciones más rápidas y consumen menos almacenamiento.
Mantenimiento más fácil: Menos software que parchear y gestionar.

Elegir imágenes base mínimas

alpine Linux: Pequeña y popular, pero prueba la compatibilidad porque usa musl libc en lugar de glibc.
Imágenes distroless: Contienen tu aplicación y dependencias de ejecución sin un shell o gestor de paquetes. Reducen lo que un atacante puede usar después de un compromiso, pero pueden dificultar la depuración.

Ejemplo: Usar Alpine como imagen base

En lugar de:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y --no-install-recommends tu-app

Considera:

FROM alpine:latest
RUN apk add --no-cache tu-app

Consejo: Instala solo los paquetes y dependencias que tu aplicación necesita absolutamente. Evita instalar herramientas de desarrollo, shells o utilidades innecesarias en imágenes de producción.

3. Ejecuta contenedores como usuarios no root

A menos que la imagen especifique otro usuario, los procesos dentro de un contenedor de Docker se ejecutan como root. Si un atacante obtiene ejecución de código en ese contenedor, root dentro del contenedor le da más margen para modificar archivos, abusar de volúmenes montados o combinar el compromiso con una mala configuración de Docker o del kernel.

Los riesgos de ejecutar como root

Escalada de privilegios: Si un contenedor se ve comprometido, el atacante tiene acceso completo como root dentro del contenedor. Si el contenedor tiene privilegios excesivos en el host, esto puede llevar a un compromiso del host.
Manipulación de datos: Los usuarios root pueden modificar cualquier archivo dentro del sistema de archivos del contenedor.

Implementar ejecución no root

Crear un usuario dedicado: En tu Dockerfile, crea un usuario y grupo no root, y luego cambia a ese usuario antes de ejecutar tu aplicación.
Establecer permisos de archivos: Asegúrate de que los archivos y directorios de la aplicación sean propiedad del usuario no root.

Fragmento de ejemplo de Dockerfile:

# Crear un usuario y grupo no root
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# Copiar archivos de la aplicación y establecer propiedad
COPY --chown=appuser:appgroup /app /app

# Cambiar al usuario no root
USER appuser

# Establecer directorio de trabajo
WORKDIR /app

# Comando para ejecutar tu aplicación
CMD ["tu-ejecutable-app"]

Advertencia: Asegúrate de que el usuario bajo el cual se ejecuta tu aplicación tenga los permisos de archivo necesarios para acceder y escribir en los directorios o archivos requeridos. Si no, tu aplicación podría no iniciarse o funcionar correctamente.

4. Implementa segmentación de red y mínimo privilegio para la comunicación entre contenedores

La red es un aspecto crítico de la seguridad de los contenedores. Los contenedores pueden comunicarse cuando comparten una red de Docker y el servicio de destino está escuchando. Trata cada red de Docker como un límite de confianza. Un contenedor web comprometido no debería alcanzar automáticamente tu base de datos, caché, interfaz de administración o trabajos internos.

Beneficios de la segmentación de red

Limitar el radio de explosión: Si un contenedor se ve comprometido, la segmentación de red puede evitar que acceda a otros contenedores o servicios sensibles.
Controlar el flujo de tráfico: Define con precisión qué contenedores pueden comunicarse entre sí y en qué puertos.
Mejorar la postura de seguridad: Aplica el principio de mínimo privilegio para el acceso a la red.

Mejores prácticas de red de Docker

Usar redes definidas por el usuario: En lugar de depender de la red bridge predeterminada, crea redes personalizadas para cada aplicación o nivel. Las redes bridge definidas por el usuario también proporcionan descubrimiento de servicios basado en DNS por nombre de contenedor.
```
docker network create mi-red-app
docker run --network mi-red-app ...
```
Limitar el acceso del contenedor: Si un frontend solo necesita llamar a una API, coloca esos dos servicios en una red y mantén la base de datos en una red de backend separada compartida solo con la API.
Usar reglas de firewall (a nivel de host): Implementa reglas de firewall a nivel de host (por ejemplo, iptables) para restringir aún más el tráfico de red hacia y desde los contenedores.
Considerar plugins de red: Para políticas y segmentación de red más avanzadas, explora los plugins de red de Docker o plataformas de orquestación de contenedores como Kubernetes, que ofrecen políticas de red sofisticadas.

Consejo: Revisa regularmente tus configuraciones de red de contenedores y listas de control de acceso para asegurarte de que se alineen con tus requisitos de seguridad y el principio de mínimo privilegio.

5. Asegura tu daemon de Docker y el host

El daemon de Docker en sí mismo es un componente poderoso que interactúa directamente con el sistema operativo host. Si el daemon de Docker se ve comprometido, un atacante podría obtener un control significativo sobre todo tu entorno Docker, incluida la máquina host.

Asegurar el daemon de Docker

Restringir el acceso al daemon: Asegúrate de que el socket del daemon de Docker (/var/run/docker.sock) no esté expuesto a usuarios o aplicaciones no confiables. Solo concede acceso a usuarios autorizados.
Usar TLS para acceso remoto al daemon: Si expones la API de Docker a través de TCP, protégela con TLS y autenticación de cliente. Evita exponerla a menos que tengas una necesidad operativa clara.
Preferir el modo sin root donde sea adecuado: Docker sin root puede reducir el riesgo a nivel de host para algunas cargas de trabajo, aunque tiene compensaciones de red y funcionalidad que debes probar.

Asegurar el host de Docker

Mantener el sistema operativo host actualizado: Parchea y actualiza regularmente el sistema operativo subyacente de tu host Docker para corregir vulnerabilidades de seguridad.
Endurecer el host: Aplica configuraciones de endurecimiento de seguridad a la máquina host, como deshabilitar servicios innecesarios, configurar firewalls y aplicar controles de acceso sólidos.
Monitorear la actividad del host: Implementa registro y monitoreo robustos para el host Docker con el fin de detectar actividades sospechosas.
Usar herramientas de seguridad: Emplea detección de intrusiones basada en host, registro de auditoría y monitoreo en tiempo de ejecución donde se ajusten a tu entorno.
Eliminar privilegios innecesarios: Evita --privileged, elimina las capacidades de Linux que no necesites y usa sistemas de archivos de solo lectura donde tu aplicación lo soporte.

Mejor práctica: Audita regularmente la configuración de tu daemon de Docker y la postura de seguridad de tus hosts Docker. Considera usar herramientas de evaluación comparativa de seguridad como CIS Docker Benchmark para evaluar y mejorar tus configuraciones de seguridad.

Conclusión

Haz de la seguridad de Docker parte de la ruta de entrega normal. Escanea imágenes en CI, mantén las imágenes de producción pequeñas, ejecuta como un usuario no root, aísla los servicios por red y protege el host Docker como un sistema de alto valor. Comienza con un servicio, aplica estos controles y luego convierte el patrón en tu plantilla predeterminada.