Riesgos planteados por el demonio docker que se ejecuta como root

El daemon docker se ejecuta como root, ya que se interconecta con el sistema operativo host de manera fundamental, sin embargo, no es diferente a la mayoría de los daemon del sistema que utilizan las capacidades de Linux que requieren ese privilegio.

Esto no significa que el uso de la ventana acoplable sea inseguro, solo que debes tener cuidado con la forma en que lo usas. Afortunadamente, ya hay algunos consejos de configuración de seguridad bastante buenos disponibles en Docker ellos mismos y en forma de seguridad guía de configuración de "mejores prácticas" de la Centro de seguridad de Internet

Un par de consideraciones prácticas que debe tener en cuenta al ejecutar la ventana acoplable.

Lo primero es que si alguien es miembro del grupo "docker" en el host, efectivamente será root en el sistema, ya que es posible usar la ventana acoplable para aumentar los privilegios en este caso. Por lo tanto, debe tratar la membresía de ese grupo en los hosts de producción con cuidado.

Docker usa las capacidades de Linux para restringir las acciones que puede realizar un usuario dentro de un contenedor, por lo que el hecho de ser root dentro de un contenedor no significa necesariamente una raíz automática en el host. Dicho esto, debe tener cuidado con cosas como los montajes de volumen (por ejemplo, si monta un directorio del sistema del host en un contenedor), ya que esto puede permitir que un usuario root dentro de un contenedor realice cambios en los archivos del host.

También puede reducir las capacidades proporcionadas a un contenedor con bastante facilidad, lo que puede mejorar aún más la seguridad del proceso.

Recuerde también que no necesita ejecutar procesos en contenedores como root, puede ejecutar como otros usuarios con un poco de configuración, y esto mitiga el riesgo de aumento de volumen.

Encuentro que la manera de pensar en los contenedores es como procesos en el host. Si compara las cosas que se ejecutan en contenedores con las que se ejecutan directamente en el host, yo diría que es probable que la arquitectura del contenedor agregue seguridad en lugar de eliminarla, ya que tiene una interfaz mejor definida entre el proceso y el host y más control sobre lo que el proceso puede hacer en el host.

Tampoco vale la pena que una arquitectura de mapeo de usuarios más rica llegue pronto a la ventana acoplable ( planeada para 1.9 ) que agregará algunas opciones más para restringir acciones en un contenedor.

No, no lo estás.

O, dicho de otra manera, si se equivoca al estar preocupado, hay muchos expertos en seguridad que están igualmente equivocados. Solo para tomar algunos ejemplos prominentes:

-Los expertos entrevistaron a aquí sobre Docker seguridad, y específicamente sobre el problema de la raíz del daemon. Incluyendo un chico de CERT:

  

Sí, eso es correcto, Docker, y muchas otras tecnologías de contenedores, necesitan   Acceso root para hacer su magia. Y, como cualquier otro programa que necesite.   Acceso a la raíz, con gran poder viene grandes oportunidades para romper   estragos.

     

Como Aaron Cois, investigador del CERT en la Universidad Carnegie Mellon   Recientemente le dije a la publicación de DevOps, "Una de las mayores amenazas que   Ver con Docker es su posicionamiento y la seguridad implícita en el   idioma. La realidad es que estos contenedores no contienen   cualquier cosa ". Con el acceso de root, ese es el caso.

Además, ejecutar cualquier cosa con privilegios de root dentro del contenedor aparentemente es problemático "Un proceso que se ejecuta como root (UID 0) en un contenedor tiene privilegios de nivel de root en el host subyacente al interactuar con el kernel".

Esa pieza proporciona un poco más sobre los aspectos específicos de los problemas relacionados con el estado raíz del daemon en particular, y una buena descripción general de los problemas de seguridad que son un poco preocupantes para Docker en general.

- Aquí está un análisis realmente bueno de un equipo que habla sobre una serie de problemas de seguridad relacionados con Docker, incluidos algunos relacionados directamente con la arquitectura de daemon-as-root, y cómo combatirlos / mitigarlos. Los presentadores aquí ofrecen una visión mixta y algo positiva de la seguridad de Docker en general, pero dejan claro que hay una serie de posibles vectores de amenaza que deben estar en la mente de uno al crear una configuración.

Me entiendes, creo. (Google revela muchas más piezas que articulan esos puntos, y yo personalmente he leído algunos otros aquí y allá durante el último año o así.) Ahora, no estoy atacando a Docker por ningún lado de la imaginación, y parece que si su cuidado en la forma en que configura y mantiene las cosas puede reducir en gran medida las amenazas que la arquitectura de seguridad menos sólida que Docker permite que existan, incluido el deamon-as-root. (Y, ciertamente, los contenedores son fáciles y cómodos de usar para todos). Pero definitivamente, no está equivocado por tener algunas preocupaciones sobre Docker no usando un buen enfoque moderno que incluye la máxima reducción de privilegios razonables (como Docker se encuentra hoy, al menos).

El artículo de Daniel Walsh, líder del RHEL Docker enablement team (así que no es el tipo de persona que tendría alguna razón para luchar contra Docker), sobre la seguridad de Docker también es interesante. Uno de los pensamientos clave es que uno debe " simplemente asumir que los procesos privilegiados que se ejecutan dentro del contenedor son los igual que los procesos privilegiados que se ejecutan fuera del contenedor. ".

Este es un artículo relativamente antiguo, julio de 2014. Los contenedores de Linux (en los que se basa Docker) han evolucionado y en enero de 2014 introdujeron contenedores sin privilegios, lo que garantiza que los procesos privilegiados dentro del contenedor se ejecutan ahora con privilegios de usuarios finales del sistema host punto de vista.

Sin embargo, esta función aún no es compatible con Docker y se pospuso varias veces.

En otra respuesta relacionada con la seguridad de Docker también mencioné otros proyectos orientados a la seguridad que dependían de Docker antes dejándolo por cuestiones de seguridad.

Entonces, como usted dijo, Docker " promete simplificar nuestras implementaciones y ofrecer una serie de otros beneficios operativos y de diseño ", esto es ciertamente cierto y parece ser el objetivo principal de Docker, pero Como lo destacó Daniel Walsh, la seguridad a través del aislamiento no forma parte de estas promesas.

Con frecuencia, existe un compromiso entre la seguridad y la funcionalidad. Docker parece posicionarse en el lado de la funcionalidad de la escalera. Depende de usted decidir si el valor agregado de las características de Docker vale la pena.