¿Es seguro confiar en un contenedor Docker?

En este momento no hay manera de determinar fácilmente si confiar en los contenedores específicos de la ventana acoplable. Docker y los proveedores de sistemas operativos proporcionan contenedores básicos a los que llaman "confiables", pero el software aún no cuenta con buenos mecanismos (por ejemplo, firma digital) para verificar que las imágenes no hayan sido manipuladas.

Para aclarar, citar el estándar de seguridad de CIS para el docker sección 4.2

  

Los repositorios oficiales son imágenes de Docker conservadas y optimizadas por la comunidad de Docker o el proveedor. Pero, la característica de firma y verificación de la imagen del contenedor Docker aún no está lista.

     

Por lo tanto, el motor Docker no verifica la procedencia de las imágenes del contenedor por sí mismo.

     

Por lo tanto, debe tener mucho cuidado al obtener imágenes de contenedor.

Cuando te metes en el mundo de los contenedores generales de terceros desde Docker hub, la imagen es aún más complicada. AFAIK docker no hace no la comprobación de los archivos contenedores de otras personas, por lo que hay una serie de posibles problemas

• El contenedor contiene malware real. Es probable que nadie lo sepa. Es posible, sí.
• El contenedor contiene software inseguro. Los Dockerfiles son básicamente como scripts por lotes que construyen una máquina. He visto varios que hacen cosas como descargar archivos a través de conexiones HTTP sin cifrar y luego ejecutarlos como root en el contenedor. Para mí, esa no es una buena manera de obtener un contenedor seguro
• El contenedor establece una configuración insegura. Docker se basa en automatizar la configuración del software, lo que significa que, en cierta medida, confía en que todas las personas que crearon los archivos docker los configuraron de forma tan segura como le hubiera gustado.

Por supuesto, puedes auditar todos los archivos docker, ¡pero una vez que lo hayas hecho, habrías sido mejor simplemente configurando el archivo tú mismo!

En cuanto a si esto "vale el riesgo", me temo que es una decisión que solo usted puede tomar. Está cambiando el tiempo necesario para desarrollar y mantener sus propias imágenes, frente a los mayores riesgos de que una persona involucrada en la producción del software que descargue sea malintencionada o haya cometido un error con respecto a la seguridad del sistema.

Confíe en él tanto como cualquier código sin firmar que ejecute en sus sistemas. Los contenedores son solo procesos con algunas protecciones de espacio de nombres adicionales, por lo que son todas las protecciones que reciben. Todavía hablan con el mismo núcleo debajo.

Es mejor considerar que un contenedor Docker es lo mismo que ejecutar una aplicación en el sistema host. Hay algunos intentos de bloquear el demonio Docker eliminando las capacidades del kernel de Linux, pero esto no es realmente una garantía. Si ejecuta Docker, hay algunas cosas que puede hacer para ayudar a mitigar parte de este riesgo.

• SELinux - Habilitar esto generará automáticamente una etiqueta MCS para cada contenedor, limitando su capacidad de hacer daño.
• Solo lectura : también puede marcar el contenedor como solo lectura, lo que le permite obtener grandes porciones de la imagen del contenedor como solo lectura, lo que puede dificultar la implementación de malware por parte de un atacante.
• Registro auto hospedado: para reducir el riesgo de alteración de la imagen, cargar contenedores maliciosos, filtrar secretos o ponerse en riesgo, puede alojar un registro internamente. enlace es un ejemplo de uno que se encuentra sobre el S3, aunque también hay otras opciones.

En esencia, sostengo que es la misma pregunta que si el software de código abierto es confiable. Pero creo que el riesgo de usar contenedores de Docker de la comunidad es un poco más alto en la actualidad que los riesgos de usar software de código abierto.

Primero, como mencionaste, ahora no hay firma ni verificación. Hoy en día, los buenos sistemas de empaquetado de código abierto incluyen este , al menos al obtener software de los repositorios oficiales. E incluso los proyectos únicos tienden a incluir sumas de comprobación en los paquetes de descarga. Entonces, en el mundo del código abierto, no sabes que el código es seguro, pero a menudo sabes que estás obteniendo el código que se supone que debes obtener. Con Docker, ni siquiera sabe que el contenedor no se altera entre la publicación y su descarga.

Segundo es el problema del paquete en sí. ¿Está seguro de que el software no está haciendo algo desagradable, como informar sus actividades a algún destino de Internet? Este solía ser un temor común al software de código abierto . Hoy en día, muchas grandes empresas no cuestionan a los implementadores técnicos que incorporan software de código abierto. Podría decirse que el software de código cerrado podría ser peor de esta manera. Pero para un contenedor Docker, especialmente uno que incluye un conjunto completo de herramientas y bibliotecas del sistema operativo, la "superficie de ataque" es mucho más grande. Si cree que puede estar usando una versión incorrecta de Postfix, solo obtenga el código oficial y créelo (y algunos administradores de paquetes lo hacen normalmente). Si crees que tienes un mal contenedor de Docker, a menudo es una aventura reproducir la imagen "desde la fuente".

¿Se puede confiar en los contenedores de seguridad de la ventana acoplable? Creo que la respuesta a esto casi siempre debe ser NO!

En mi caso, me pregunto acerca de 'linuxserver / openvpn-as'. Vaya, ¿no sería bueno simplemente meter esa cosa en uno de mis enjambres de docker, abrirlo en mis redes privadas y dejar que administre el acceso de usuarios remotos a esas redes? Pero, ¿cómo puedo confiar algo como esto en cualquier contenedor que salga de la web y que no tenga procedencia? Sin eso, no creo que pueda.

Si tuviera procedencia, solo tendría que confiar en el creador para que tenga

1. comenzó con algo igualmente confiable (y así sucesivamente),
2. no se ha hecho algo malicioso, y
3. no hizo una elección insegura para un paso de instalación o configuración.

Este es un orden bastante alto en sí mismo. En este caso, tengo que confiar en linuxserver.io. Nunca he escuchado de ellos. Pero mirándolos, parece que todo su trabajo es crear contenedores. Así que probablemente son muy buenos en eso. Y este contenedor supuestamente ha sido descargado de DockerHub más de 500K veces. Suena como algo bastante seguro.

Por lo tanto, probablemente podría sentirme bastante bien si pudiera estar seguro de que la imagen que estoy obteniendo

1. fue creado por linuxserver.io, y
2. es, de hecho, LA imagen que realmente se ha descargado 500K veces.

Primero que nada, (2) no es verdad, ¿verdad? Eso es contar todas las versiones del contenedor, creo. Tal vez el contenedor haya estado seguro durante años, pero alguien SOLO lanzó una versión con un grave agujero de seguridad. Y luego está (1). Ese es el verdadero apestoso. ¿En cuántos otros mecanismos debo confiar (DockerHub, el proveedor de DockerHub, la infraestructura de Internet, ...) para estar seguro de que el código fuente original para el contenedor que linuxserver.io considera como la fuente para el contenedor realmente define completamente el contenedor que realmente estoy usando. No hay manera de que pueda saber eso. Y, realmente, tendría que saber que no solo sobre este contenedor, sino sobre todos los sub-contenedores usados para crearlo. Así que no puedo usar este contenedor.

Este es un caso extremo, pero probablemente no lo sea para ningún contenedor que incluya seguridad de red. Espero que muchos de esos 500K consumidores que realmente usaron esta imagen lo hicieran de manera imprudente, sin la culpa de linuxserver.io.

Docker necesita un mecanismo de procedencia de contenedor completo. Incluso entonces, hay una gran cantidad de confianza para reunir aquí. Tal vez demasiado grande. Tal vez el software de seguridad simplemente no es capaz de contener en contenedores.

Puede generar confianza en la fuente mediante una investigación rápida, pero una preocupación más fundamental es la relativa inmadurez del perfil de seguridad general, como lo sugiere la necesidad de usar el acceso de raíz para ejecutar su contenedor.

Como sugiere que nos enfoquemos en soluciones populares, consideremos que estamos usando un repositorio controlado basado en Git como Docker Hub para derribar un producto popular suministrado por un proveedor. Los mecanismos Git proporcionan una buena capa de confianza. Si confía en el proveedor nombrado, puede confiar en su producto Docker. Si recuerda algunos años atrás, GitHub se vio comprometido pero el código fuente estaba bien debido al mecanismo de firma de integridad de Git y los controles de publicación. Estas características también protegen los archivos publicados de Docker si está utilizando productos de proveedores populares.

El Dockerfile que construye su contenedor puede alcanzar y descargar archivos tar, etc. que no están alojados en repositorios Git de confianza. Una simple comprobación de ese archivo de texto, el Dockerfile, puede generar confianza en ese espacio.

Los mecanismos de seguridad generales son muy jóvenes, así que considere sus vulnerabilidades además de los problemas de control de la fuente. De su documentación sobre seguridad:

Hay tres áreas principales a considerar al revisar la seguridad de Docker:

• la seguridad intrínseca del kernel y su soporte para espacios de nombres y cgroups
• la superficie de ataque del propio demonio Docker
• lagunas en el perfil de configuración del contenedor, ya sea de forma predeterminada o cuando lo personalizan los usuarios
• las características de seguridad de "endurecimiento" del kernel y cómo interactúan con los contenedores

Creo que el hecho de que su página principal sobre seguridad dice que hay tres áreas principales y luego enumera cuatro es otra indicación de que las cosas están cambiando en ese espacio. Parece ser una solución fantástica, pero puede necesitar cierto fortalecimiento inteligente con los perímetros y políticas proporcionados por el usuario en el corto plazo.

Específicamente, con Docker, en mi experiencia, puede confiar en que la gran mayoría de las cosas que hay en la comunidad de código abierto (como las de Github) no serán deliberadamente maliciosas. Puede leer el Dockerfile y verificar que está obteniendo el código de los repositorios oficiales, en caso de que haya alguno (en lugar de usar el tenedor de alguna persona aleatoria). Si está extrayendo el código de algún lugar extraño, por supuesto, siempre puede echar un vistazo a lo que es diferente del repositorio oficial en esa bifurcación específica. Aquí es donde te metes en un software malicioso que no es malicioso intencionalmente . Es solo un código basura o una configuración horrible o equivalente. En mi experiencia con Docker, el código que utiliza horquillas no oficiales debe evitarse, a menos que la bifurcación proporcione una característica específica que está buscando. El repositorio oficial se actualizará más a menudo que el fork, casi en todas partes. Además, Docker utiliza lo que se conoce como "compilaciones de confianza" para que sepa que está obteniendo lo que dice que está obteniendo en la lata. Finalmente, el propio Docker ha tenido vulnerabilidades. Parece que tienes la mentalidad correcta para darte una corazonada si algo parece mal.

En pocas palabras, generalmente si sus recursos de Docker obtienen FROM de una compilación oficial, y desde los repositorios oficiales, esto es lo más seguro que puede usar el software. El propio Docker ha tenido su parte de vulnerabilidades, pero mientras esté al tanto de parchear su infraestructura, estará bien.

Asuma la postura predeterminada de no confiar en nada que quiera traer a su entorno desde el exterior.

Si es algo que realmente quieres usar, minimiza el riesgo tanto como sea posible mediante el secuestro, el análisis y asegurándote de que no hará ningún daño.

Dale el menor acceso posible a tu entorno para que pueda hacer lo que necesitas que haga.

Compruébalo. Actualícelo y asegúrese de que las actualizaciones no presenten un nuevo riesgo.