Pregunta ¿Cómo manejar las actualizaciones de seguridad dentro de los contenedores Docker?


Cuando se implementan aplicaciones en los servidores, generalmente existe una separación entre lo que la aplicación incluye y lo que espera de la plataforma (sistema operativo y paquetes instalados) para proporcionar. Un punto de esto es que la plataforma se puede actualizar independientemente de la aplicación. Esto es útil, por ejemplo, cuando las actualizaciones de seguridad deben aplicarse con urgencia a los paquetes proporcionados por la plataforma sin reconstruir toda la aplicación.

Tradicionalmente, las actualizaciones de seguridad se han aplicado simplemente ejecutando un comando del administrador de paquetes para instalar versiones actualizadas de paquetes en el sistema operativo (por ejemplo, "yum update" en RHEL). Pero con el advenimiento de la tecnología de contenedores como Docker, donde las imágenes de los contenedores esencialmente agrupan la aplicación y La plataforma, ¿cuál es la forma canónica de mantener actualizado un sistema con contenedores? Tanto el host como los contenedores tienen su propio e independiente conjunto de paquetes que necesitan actualización y actualización en el host no actualizarán ningún paquete dentro de los contenedores. Con el lanzamiento de RHEL 7, donde se muestran especialmente los contenedores Docker, sería interesante conocer cuál es la forma recomendada por Redhat para manejar las actualizaciones de seguridad de los contenedores.

Reflexiones sobre algunas de las opciones:

  • Dejar que los paquetes de actualización del administrador de paquetes en el host no actualicen los paquetes dentro de los contenedores.
  • Tener que regenerar todas las imágenes del contenedor para aplicar las actualizaciones parece romper la separación entre la aplicación y la plataforma (la actualización de la plataforma requiere acceso al proceso de creación de la aplicación que genera las imágenes de Docker).
  • Ejecutar comandos manuales dentro de cada uno de los contenedores en ejecución parece engorroso y los cambios corren el riesgo de que se sobrescriban la próxima vez que se actualicen los contenedores desde los artefactos de lanzamiento de la aplicación.

Entonces ninguno de estos enfoques parece satisfactorio.


103
2017-07-08 21:54


origen


La mejor idea para esto que he visto hasta ahora es Proyecto atómico. No creo que sea bastante listo para el horario de máxima audiencia sin embargo. - Michael Hampton♦
Valko, ¿con qué flujo de trabajo terminaste? Estoy ejecutando contenedores a largo plazo (albergando php-cgi, por ejemplo) y lo que he encontrado hasta ahora es: docker pull debian/jessie para actualizar la imagen, luego reconstruir mis imágenes existentes, luego detener los contenedores y ejecutarlos nuevamente (con la nueva imagen). Las imágenes que construyo tienen el mismo nombre que las anteriores, por lo que el inicio se realiza a través del script. Luego elimino las imágenes "sin nombre". Seguramente apreciaría un mejor flujo de trabajo. - miha
miha: Eso suena similar a lo que he terminado haciendo. Básicamente, continuamente se actualizan y se reconstruyen todas las imágenes como parte de la creación de nuevos lanzamientos. Y reiniciando los contenedores utilizando las nuevas imágenes. - Markus Hallmann
La mejor respuesta aquí ayuda mucho porque hay un script que contiene las principales líneas de comando para hacer exactamente lo que dijo Johannes Ziemke: - Hudson Santos


Respuestas:


Una aplicación de paquetes de imágenes Docker y "plataforma", eso es correcto. Pero normalmente la imagen está compuesta por una imagen base y la aplicación real.

Así que la forma canónica de manejar las actualizaciones de seguridad es actualizar la imagen base y luego reconstruir la imagen de la aplicación.


43
2017-08-12 11:41



Gracias, esto suena razonable. Todavía deseo actualizar la plataforma, por así decirlo, no tendría que desencadenar el reempaquetado de la aplicación completa (considere, por ejemplo, tener que reconstruir 100 imágenes de aplicaciones diferentes debido a una actualización de una sola imagen base). Pero tal vez esto sea inevitable con la filosofía Docker de agrupar todo en una sola imagen. - Markus Hallmann
@ValkoSipuli Siempre se puede escribir un script para automatizar el proceso. - dsljanus
¿Por qué no apt-get upgrade, dnf upgrade, pacman -syu, etc. equivalentes dentro del contenedor? Incluso podrías crear un script de shell que haga eso. y entonces ejecuta la aplicación, luego la usa como punto de entrada del contenedor para que cuando el contenedor se inicie / reinicie, actualice todos sus paquetes. - Arthur Kay
@ArthurKay Dos razones: 1) Explota el tamaño del contenedor, ya que todos los paquetes que se actualicen se agregarán a la capa del contenedor, manteniendo el paquete obsoleto en la imagen. 2) Derrota la mayor ventaja de las imágenes (de contenedor): la imagen que se ejecuta no es la misma que genera / prueba porque cambia los paquetes en tiempo de ejecución. - Johannes 'fish' Ziemke
Hay una cosa que no entiendo: si usted es una empresa que compra una pieza de software que se envía como un contenedor acoplable, ¿tiene que esperar a que el fabricante del software reconstruya el paquete de la aplicación cada vez que surge un problema de seguridad? ? ¿Qué compañía renunciaría al control sobre sus vulnerabilidades abiertas de esa manera? - Sentenza


Se supone que los contenedores son ligeros e intercambiables. Si su contenedor tiene un problema de seguridad, reconstruye una versión del contenedor que está parcheado y despliega el nuevo contenedor. (muchos contenedores utilizan una imagen base estándar que utiliza herramientas de administración de paquetes estándar como apt-get para instalar sus dependencias, la reconstrucción extraerá las actualizaciones de los repositorios)

Si bien puedes parchar dentro de los contenedores, eso no va a escalar bien.


6
2017-10-03 19:44





Esto se maneja automáticamente en SUSE Enterprise Linux usando zypper-docker (1)

SUSE / zypper-docker

Inicio rápido de Docker


1
2018-05-08 17:05





En primer lugar, muchas de las actualizaciones que tradicionalmente ejecutó en el pasado simplemente no estarán dentro del contenedor. El contenedor debe ser un subconjunto bastante ligero y pequeño del sistema de archivos completo que está acostumbrado a ver en el pasado. Los paquetes que debería tener que actualizar serían aquellos que forman parte de su DockerFile, y ya que tiene el DockerFile, debería poder realizar un seguimiento de esos paquetes e ID de contenedores que necesitan actualizaciones. La interfaz de usuario de Cloudstein que se lanzará pronto hará un seguimiento de estos ingredientes de DockerFile para que pueda construir el esquema de actualización que mejor se adapte a sus contenedores. Espero que esto ayude


0
2017-07-08 23:23