tl; dr : las soluciones de contenedor no garantizan y nunca garantizarán el aislamiento completo; en su lugar, utilice la virtualización si lo necesita.
Enfoques de abajo hacia arriba y de arriba hacia abajo
Docker (y lo mismo se aplica a soluciones de contenedores similares) no garantiza un aislamiento completo y no se puede confundir con la virtualización. El aislamiento de contenedores se logra al agregar algunas barreras entre ellos, pero Aún utilizamos recursos compartidos como el kernel. Por otro lado, la virtualización tiene recursos compartidos mucho más pequeños, que ahora son más fáciles de entender y están bien probados, a menudo enriquecidos por las características de hardware para restringir el acceso. Docker describe esto en su artículo de seguridad de Docker como
Un riesgo principal al ejecutar contenedores de Docker es que el conjunto predeterminado de capacidades y montajes otorgados a un contenedor puede proporcionar un aislamiento incompleto, ya sea de forma independiente o cuando se usa en combinación con las vulnerabilidades del kernel.
Considere la virtualización como un enfoque de arriba hacia abajo
Para la virutalización, comienza con un aislamiento bastante completo y proporciona algunas interfaces bien descritas y bien guardadas; esto significa que puede estar bastante seguro de que salir de una máquina virtual es difícil. El kernel no se comparte, si tiene alguna vulnerabilidad de kernel que le permita escapar de las restricciones de los usuarios, el hipervisor se interpone entre usted y otras máquinas virtuales.
Esto no implica un aislamiento perfecto. Una y otra vez, se encuentran problemas con el hipervisor, pero la mayoría son ataques muy complicados con un alcance limitado que son difíciles de realizar (pero también son muy críticos, "fáciles de explotar").
Los contenedores, por otro lado, están de abajo hacia arriba
Con los contenedores, comienzas ejecutando aplicaciones en el mismo kernel, pero agregas barreras (espacios de nombres del kernel, cgroups, ...) para aislarlos mejor. Si bien esto proporciona algunas ventajas como una menor sobrecarga, es mucho más difícil "estar seguro" de no haber olvidado nada, el Kernel de Linux es una pieza de software muy grande y compleja. Y el kernel en sí todavía se comparte, si hay una vulnerabilidad en el kernel, es muy probable que pueda escapar al host (y / u otros contenedores).
Usuarios dentro y fuera de contenedores
Especialmente antes de Docker 1.9 que debería obtener los espacios de nombres de los usuarios significa que "la raíz del contenedor también tiene privilegios de raíz de host "tan pronto como se encuentre otra barrera faltante en la máquina Docker (o la vulnerabilidad del núcleo). Ha habido tales problemas antes , debe esperar más por venir y Docker recomienda que
tenga cuidado de ejecutar sus procesos dentro de los contenedores como usuarios sin privilegios (es decir, no root).
Si está interesado en obtener más detalles, estep publicó un buen artículo en http://integratedcode.us que explica los espacios de nombres de los usuarios .
Restringir el acceso de root (por ejemplo, imponer a un usuario sin privilegios al crear la imagen o al menos usar los nuevos espacios de nombres de usuario) es una medida de seguridad básica y necesaria para proporcionar aislamiento, y puede dar a la satisfacción de aislamiento entre contenedores. El uso de espacios de nombres de usuarios y usuarios restringidos, el escape al host se vuelve mucho más difícil, pero aún así no debería estar seguro de que no haya otra forma de salir de un contenedor (y si esto incluye explotar un problema de seguridad no parcheado en el kernel ), y no debe utilizarse para ejecutar código no confiable.