Con el aumento de las aplicaciones e imágenes de la ventana acoplable, la seguridad de los contenedores de la ventana acoplable requiere más atención que nunca. Estas mejores prácticas de seguridad de Docker lo ayudarán a fortalecer el host y las aplicaciones de Docker.

Mejores prácticas de seguridad de Docker

Herramientas devOps. Git, Jenkins, Splunk, Nagios, Chef, Puppet, Ansible, Docker y Kubernetes son la lista de las principales herramientas de DevOps y como cualquier software, Docker tiene vulnerabilidades. Si no se refuerzan las vulnerabilidades de seguridad de la ventana acoplable, puede provocar un desastre. A continuación, se muestran algunos escenarios de ejemplo:

• Ejecutar un contenedor como root o privilegios elevados puede abrir la puerta para que una aplicación se haga cargo de su host Docker.
• Las imágenes de Docker que no son de confianza pueden tener código malicioso que podría comprometer datos confidenciales o incluso exponerlos intencionalmente.
• Los servicios de Docker pueden consumir intencional o involuntariamente los recursos de su host, lo que provoca fallas o que los recursos no estén disponibles para otras aplicaciones.
• Exponer el socket de docker, que es propiedad de root, a contenedores puede llevar a una toma de control de todo el sistema. Por ejemplo, Traefik requiere acceso al socket de la ventana acoplable. Entonces, si usa Traefik y si Traefik está comprometido, entonces su sistema también está comprometido.
• Una protección inadecuada (por ejemplo, un sistema de autenticación débil) puede poner en peligro sus aplicaciones web.
• El malware en Docker puede utilizar tus recursos para fines no deseados (por ejemplo, minería de cifrado).

La protección de Docker y sus aplicaciones generalmente se puede dividir en varias categorías. Veamos medidas de seguridad simples y algunas avanzadas en cada una de estas categorías.

Precaución: Nunca expongas el puerto 2375 a Internet. Esto es aún más importante para los servidores privados virtuales que normalmente exponen todos los puertos. El puerto 2375 solo debería exponerse a la red interna (127.0.0.1:2375). 

Asegurar el host de Docker

La primera categoría cubre todas las cosas diferentes que puede hacer para proteger su host de la ventana acoplable.

Mantener actualizado el host de Docker

Mantenga su sistema de host de Docker actualizado con las actualizaciones de seguridad. En una pila Docker Traefik basada en Linux, frecuentemente actualizo los paquetes y actualizo el sistema usando los siguientes comandos:

sudo apt-get update

sudo apt-get upgrade

NO Exponer socket del demonio Docker 

El socket de Docker /var/run/docker.sock es el socket de UNIX que está escuchando Docker. Este es el punto de entrada principal para la API de Docker. El propietario de este socket es root. Darle acceso a alguien es equivalente a dar acceso de root sin restricciones a su host.

No habilites tcp Docker daemon socket. Si está ejecutando el demonio de Docker con -H tcp: //0.0.0.0: XXX o similar, está exponiendo acceso directo no cifrado y no autenticado al demonio de Docker. Si realmente tiene que hacer esto, debe asegurarlo. Compruebe cómo hacer esto siguiendo la documentación oficial de Docker.

No exponga /var/run/docker.sock a otros contenedores. Si está ejecutando su imagen de la ventana acoplable con -v /var/run/docker.sock://var/run/docker.sock o similar, debe cambiarlo. Recuerde que montar el socket en modo de solo lectura no es una solución, sino que solo dificulta su explotación. El equivalente en el archivo docker-compose es algo como esto:

volumes:

- "/var/run/docker.sock:/var/run/docker.sock"  

Usar un usuario para docker

Configurar el contenedor para usar un usuario sin privilegios es la mejor manera de prevenir ataques de escalada de privilegios. Esto se puede lograr de tres formas diferentes de la siguiente manera:

     1- Durante el tiempo de ejecución usando la opción -u del comando docker run, por ejemplo:

docker run -u 4000 alpine

     2- Durante el tiempo de construcción. Simplemente agregue un usuario en Dockerfile y úselo. Por ejemplo:

FROM alpine

RUN groupadd -r myuser && useradd -r -g myuser myuser

<HERE DO WHAT YOU HAVE TO DO AS A ROOT USER LIKE INSTALLING PACKAGES ETC.>

USER myuser

     3-Habilitar la compatibilidad con el espacio de nombres de usuario (--userns-remap = predeterminado) en el demonio de Docker

  Limitar capacidades (Otorgar solo capacidades específicas, necesarias para un contenedor)

Las capacidades del kernel de Linux son un conjunto de privilegios que pueden utilizar los privilegiados. Docker, de forma predeterminada, se ejecuta solo con un subconjunto de capacidades. Puede cambiarlo y eliminar algunas capacidades (usando --cap-drop) para fortalecer sus contenedores de la ventana acoplable, o agregar algunas capacidades (usando --cap-add) si es necesario. Recuerde no ejecutar contenedores con la marca --privileged; esto agregará TODAS las capacidades del kernel de Linux al contenedor.

La configuración más segura es descartar todas las capacidades: tapar-eliminar todas y luego agregar solo las necesarias. Por ejemplo:

docker run --cap-drop all --cap-add CHOWN alpine

Y recuerda: ¡¡¡No ejecutes contenedores con el flag --privileged !!! 

Agregar el indicador –no-new-privileges

Ejecuta siempre las imágenes de la ventana acoplable con --security-opt = no-new-privileges para evitar la escalada de privilegios utilizando los binarios setuid o setgid.

Deshabilitar la comunicación entre contenedores (--icc = false) 

De forma predeterminada, la comunicación entre contenedores (icc) está habilitada, lo que significa que todos los contenedores pueden comunicarse entre sí (utilizando la red puenteada docker0). Esto se puede desactivar ejecutando el demonio docker con --icc = false flag. Si icc está deshabilitado (icc = false), es necesario indicar qué contenedores pueden comunicarse usando la opción --link = CONTAINER_NAME_or_ID: ALIAS. Más información en la documentación de Docker: comunicación de contenedores

Limitar recursos (memoria, CPU, descriptores de archivos, procesos, reinicios) 

La mejor forma de evitar los ataques DoS es limitando los recursos. Puede limitar la memoria, la CPU, la cantidad máxima de reinicios (--restart=on-failure:<number_of_restarts>), la cantidad máxima de descriptores de archivos (--ulimit nofile = <númeror>) y la cantidad máxima de procesos (--ulimit nproc = <número>). 

Utilizar un cortafuegos

Una buena práctica de seguridad de Docker es bloquear el acceso a puertos innecesarios. Hago esto usando Universal Firewall (UFW) en sistemas Debian / Ubuntu. Como se muestra en la captura de pantalla a continuación, solo permito el acceso en los puertos 80 y 443, que son utilizados por traefik. Hay otros puertos a los que solo permito el acceso desde la red privada local (192.168.0.0/16).

Utilizar un proxy inverso

Muchas de las aplicaciones de la ventana acoplable requieren que los puertos estén expuestos a Internet para poder acceder a la interfaz de usuario desde cualquier lugar.

La mejor manera es no exponer ningún puerto a Internet y, en su lugar, utilizar una VPN en su red privada y acceder a las aplicaciones localmente. Pero esto es demasiado engorroso y poner las aplicaciones detrás de un proxy inverso es una alternativa conveniente pero peor.

Deberás configurar el reenvío de puertos en su puerta de enlace de Internet para reenviar ciertos puertos al host de Docker.

Recomiendo encarecidamente no exponer todas las aplicaciones de la ventana acoplable a Internet. En su lugar, póngalos detrás de un proxy inverso. Puedes usar, Traefik y expongo solo los puertos 80 y 443 a Internet. Incluso el tablero traefik que usa el puerto 8080 está detrás de un proxy inverso.

Seguridad en Docker - Hardening

La siguiente categoría es grande: Docker. Repasemos, lo que considero, una lista de verificación de seguridad de Docker para garantizar que su configuración esté protegida.

No cambies la propiedad de Docker Socket

No cambies la propiedad de Docker Socket (/var/run/docker.sock en Linux). De forma predeterminada, el socket es propiedad del usuario root y del grupo docker

Por conveniencia, es recomendado que agregues tu usuario al grupo docker

Añadir usuario actual al grupo Docker

sudo usermod -aG docker ${USER}

El beneficio es que puede ejecutar comandos en docker sin tener que usar sudo. 

No ejecutar contenedores Docker como root

El comportamiento predeterminado es que los contenedores se ejecuten como usuario root dentro del contenedor, lo que otorga privilegios de root. Este es un riesgo de seguridad.

Una de las mejores prácticas de seguridad de Docker es ejecutar el contenedor como usuario no root (UID no 0). Las imágenes acreditadas y confiables utilizan esta buena práctica de seguridad al crear imágenes. Por ejemplo, LinuxServer.io proporciona imágenes de Docker para varias aplicaciones de servidor doméstico. Sus imágenes permiten especificar explícitamente el UID y GID como variables ambientales.

environment:

      - PUID=$PUID

      - PGID=$PGID

Utilizar el modo privilegiado con cuidado

El comportamiento predeterminado es que los contenedores Docker se ejecuten en modo "sin privilegios". Esto significa que estos contenedores no pueden ejecutar un demonio docker dentro de sí mismos. Esto también prohíbe el uso de dispositivos host o ciertas funciones del kernel.

Esto generalmente se hace agregando la siguiente línea a los servicios:

privileged: true

Algunos servicios requieren el modo privilegiado. En tales situaciones, solo use imágenes de Docker de fuentes confiables (más sobre esto más adelante). Un enfoque aún mejor es utilizar las capacidades de Docker.

Además, agregar la siguiente línea asegura que los contenedores no obtengan privilegios adicionales:

security_opt: 

- no-new-privileges:true

Utilizar imágenes de Docker de confianza

Cuando sea posible, utilice siempre imágenes de editores verificados o fuentes oficiales como se muestra a continuación.

Las imágenes oficiales en Docker Hub ofrecen seguridad de contenedor Docker Esto brinda confianza inmediata y garantiza la seguridad del contenedor Docker.

Con imágenes impopulares, es difícil predecir o adivinar si se siguieron / implementaron las mejores prácticas de seguridad de Docker.

Desafortunadamente, para muchas aplicaciones de servidor doméstico como Sonarr, Radarr, etc., no existen editores "oficiales" o "verificados". 

Utilizar los secretos de Docker

Especificar toda su información confidencial (por ejemplo, claves de API) en el archivo .env, / etc / environment o en el archivo docker-compose.yml puede ser un riesgo para la seguridad.

Esta es exactamente la razón por la que se introdujeron los secretos de Docker: para administrar datos confidenciales.

La implementación de los secretos de Docker para su pila es un proceso de varios pasos.

A. Crear carpeta de secretos

Primero, cree una carpeta de secretos dentro de la carpeta raíz de la ventana acoplable.

Como práctica recomendada de la ventana acoplable, la carpeta secrets debe ser propiedad de root

Establezca los permisos de esta carpeta en 600, propiedad de la raíz del usuario y la raíz del grupo.

sudo chown root: root ~ /docker /secrets

sudo chmod 600 ~ /docker/secrets

Esto hace que esta carpeta sea accesible solo para el usuario root, agregando una capa de seguridad al acceder a información confidencial.

B. Crear archivos secretos

A continuación, tendrá que poner su información confidencial en un archivo. Como ejemplo, definamos un secreto para el correo electrónico de la cuenta de Cloudflare.

Creemos un archivo dentro de la carpeta secretos con el nombre cloudflare_email. Recuerde que necesitará permisos de root para crear el archivo. En mi sistema Ubuntu, uso:

sudo su

nano cloudflare_email

Puede utilizar cualquier otro editor de texto.

En el archivo, lo único que debe agregarse es el correo electrónico de su cuenta de Cloudflare, como se puede ver en mi GitHub Repo.

Guardar y Salir.

C. Definir secretos en Docker Compose File

Ahora que se ha creado el secreto de Docker, defínalo en el archivo de redacción de Docker. Esto se hace usando los secretos: block.

El siguiente ejemplo muestra dos secretos: cloudflare_email y cloudflare_api_key.

########################### SECRETS

secrets:

  cloudflare_email:

    file: $SECRETSDIR/cloudflare_email

  cloudflare_api_key:

    file: $SECRETSDIR/cloudflare_api_key

$ SECRETSDIR es la variable de entorno que contiene la ruta a la carpeta de secretos de Docker. 

Utilizar los secretos en los servicios de Docker

Una vez definidos globalmente, podemos usar los secretos en los fragmentos de docker-compose para servicios individuales. Dado que agregamos los detalles de la cuenta de Cloudflare como secretos de Docker, veamos cómo usarlos en el fragmento de Docker-compose para Traefik.

Primero, tenemos que hacer que los secretos estén disponibles dentro del contenedor Traefik. Para hacer esto, debe agregar el siguiente bloque al fragmento de docker-compose para Traefik:

   secrets:

      - cloudflare_email

      - cloudflare_api_key

Lo que hace es que hace que el archivo secreto esté disponible en la carpeta / run / secrets dentro del contenedor.

A continuación, podemos configurar las variables de entorno para leer datos confidenciales de estos archivos secretos utilizando el entorno: block, como se muestra a continuación:

  environment:

      - CF_API_EMAIL_FILE=/run/secrets/cloudflare_email

      - CF_API_KEY_FILE=/run/secrets/cloudflare_api_key

Observa que las variables ambientales ahora tienen _FILE anexado al final. No lo omitas o no funcionará.

Guarda y vuelva a crear el servicio (en este caso Traefik) y compruebe los registros para ver si hay errores. Si Traefik no puede leer los secretos correctamente, lo verá como un error en los registros.

Para que los secretos de Docker funcionen correctamente, la imagen base del contenedor debe admitirlo. Si la imagen es una imagen reputada / confiable, es muy probable que los desarrolladores hayan implementado las mejores prácticas de seguridad de Docker, incluidos los secretos de Docker.

Controlar el uso de recursos de Docker

Poder establecer recursos para los servicios de Docker solo es posible con la versión 2 de Docker-Compose o el modo Docker Swarm.

Si está utilizando cualquiera de esos, puede establecer límites de recursos para los servicios de Docker.

A continuación, se muestra un ejemplo de docker-compose para establecer límites de recursos en el modo Docker Swarm:

    deploy:

      resources:

        limits:

          cpus: '0.50'

          memory: 50M

        reservations:

          cpus: '0.25'

          memory: 20M

Recuerda: 

Utilizar Herramientas para Auditar  la Seguridad Contenedores Docker

Fuentes:

https://www.smarthomebeginner.com/traefik-docker-security-best-practices/

https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html