Cómo deshabilitar que el demonio de Docker monte el sistema de archivos raíz del host en el contenedor

Tengo la siguiente configuración de contenedor.

En un servidor básico, se instalan y ejecutan dos demonios de Docker.

  1. Demonio Principal de Docker Ejecuta mis contenedores de aplicaciones exponiendo 80/443 al mundo exterior.
  2. Demonio de la Ventana Acoplable del Complemento Ejecuta algunos contenedores proporcionados por el cliente que se comunican con mi aplicación a través de 80/443.

Me gustaría dar acceso al cliente a la API (2376) de la Demonio de la Ventana Acoplable del Complemento para que el cliente pueda desplegar / iniciar / detener sus propios contenedores. El cliente solo tendrá acceso a la API, no al Host (SSH).

El problema al que me enfrento actualmente es, ¿qué pasa si los clientes ejecutan un contenedor que hace algo inseguro como docker run -v /:/host/root Ubuntu rm -rf /host/root.

Mi pregunta es qué puedo hacer para prevenir el Demonio de la Ventana Acoplable del Complemento desde la raíz / o cualquier otro directorio externo /home/user/,

  • Es una opción para iniciar el demonio Docker en /home/user/?
  • ¿Puedo usar algo de magia LSM (Módulos de Seguridad de Linux SELinux/Apparmor) para evitar que el demonio docker monte algunas o todas las rutas de host, excepto el inicio de los usuarios o var/docker/libs?
  • Puede --userns-remap ¿me ayudas a conseguir mi objetivo?
  • Hay otras opciones disponibles, excepto VMs?

El servidor pertenece completamente a un solo cliente. Por lo tanto, la seguridad o la fuga de datos no es mi principal preocupación. Lo que realmente quiero evitar es que alguien en Plugin Demonio está haciendo algo estúpido, que influye en mis contenedores que se ejecutan en Demonio Principal de Docker. Me gustaría mantenerme delgado y ceñirme al flujo de trabajo solo de docker y no quiero configurar un flujo de trabajo adicional para la creación de VM.

SELinux evitará que cualquier cosa que no esté correctamente etiquetada se monte como un volumen dentro de un contenedor docker, como prueba, aquí usando un solo archivo, la misma política se aplica a los directorios:

$ sestatusSELinux status:                 enabledSELinuxfs mount:                /sys/fs/selinuxSELinux root directory:         /etc/selinuxLoaded policy name:             targetedCurrent mode:                   enforcingMode from config file:          enforcingPolicy MLS status:              enabledPolicy deny_unknown status:     allowedMax kernel policy version:      30

Uso del archivo de muestra:

$ cat sample_script.sh echo 'Hello, world'

Su contexto de seguridad predeterminado es:

$ ls -lrtZ sample_script.sh -rw-------. 1 david david unconfined_u:object_r:user_home_t:s0 20 Oct  3 17:18 sample_script.sh

Intentar usar este archivo dentro de un contenedor falla como se esperaba:

$ docker run -v /home/david/sample_script.sh:/sample_script.sh --rm ubuntu bash sample_script.shbash: sample_script.sh: Permission denied

Y se registrará una denegación de AVC:

$ sudo ausearch -m avc -ts recenttime->Mon Oct  3 17:39:28 2016type=AVC msg=audit(1475512768.444:784): avc:  denied  { read } for  pid=28720 comm="bash" name="sample_script.sh" dev="dm-13" ino=101062112 scontext=system_u:system_r:svirt_lxc_net_t:s0:c457,c992 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0

Después de cambiar el contexto de seguridad a uno, Docker puede usar:

$ sudo chcon -Rt svirt_sandbox_file_t sample_script.sh$ ls -lrtZ sample_script.sh -rw-------. 1 david david unconfined_u:object_r:svirt_sandbox_file_t:s0 20 Oct  3 17:18 sample_script.sh 

El contenedor ahora tiene acceso al archivo:

$ docker run -v /home/david/sample_script.sh:/sample_script.sh --rm ubuntu bash sample_script.shHello, world

Más información sobre Docker y SELinux en el documentación oficial de Red Hat y este artículo por Dan Walsh.

Sí, SELinux previene este ataque. Mostrar que no funciona es una buena demostración. Utilice Docker en una distribución basada en Red Hat para obtener acceso a la protección de SELinux. En las distribuciones basadas en Debian, SELinux históricamente no se ha mantenido bien.

¿Qué hay de Apparmor, es posible allí también?

No lo creo. Nunca he oído que AppArmor sea capaz de hacer algo como esto. Es una tecnología bastante diferente y mucho menos segura, ya sabes.