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

Al implementar aplicaciones en servidores, generalmente hay una separación entre lo que la aplicación agrupa consigo misma y lo que espera de la plataforma (sistema operativo y paquetes instalados). 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 contenedores esencialmente agrupan tanto la aplicación como la plataforma, ¿cuál es la forma canónica de mantener actualizado un sistema con contenedores? Tanto el host como los contenedores tienen sus propios conjuntos de paquetes independientes que deben actualizarse y actualizar en el host no actualizará ningún paquete dentro de los contenedores. Con el lanzamiento de RHEL 7, donde los contenedores Docker se presentan especialmente, sería interesante saber 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 el administrador de paquetes actualice los paquetes en el host no actualizará los paquetes dentro de los contenedores.
• Tener que regenerar todas las imágenes del contenedor para aplicar 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).
• La ejecución de comandos manuales dentro de cada uno de los contenedores en ejecución parece engorrosa y los cambios corren el riesgo de sobrescribirse la próxima vez que los contenedores se actualicen desde los artefactos de lanzamiento de la aplicación.

Por lo tanto, ninguno de estos enfoques parece satisfactorio.

Una aplicación de paquetes de imágenes de Docker y una "plataforma", eso es correcto. Pero, por lo general, la imagen se compone de una imagen base y la aplicación real.

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

Se supone que los contenedores son livianos e intercambiables. Si su contenedor tiene un problema de seguridad, reconstruya una versión del contenedor que está parcheada e implemente el nuevo contenedor. (muchos contenedores usan una imagen base estándar que usa 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.

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

SUSE / zypper-docker

Inicio rápido de Docker

En primer lugar, muchas de sus 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 los que forman parte de su DockerFile, y dado que tiene el DockerFile, debería poder realizar un seguimiento de los paquetes y las ID de contenedores que necesitan actualizaciones. La interfaz de usuario de Cloudstein que se lanzará pronto realiza un seguimiento de estos ingredientes de DockerFile para que pueda crear el esquema de actualización que mejor se adapte a sus contenedores. Espero que esto ayude

generalmente es incluso peor que las tres opciones que proporcionó. La mayoría de las imágenes de Docker no están compiladas con gestores de paquetes, por lo tanto, no puede simplemente acceder a la imagen de Docker y emitir una actualización. Deberá reconstruir o volver a obtener la imagen del acoplador.

El hecho de que necesite reconstruir o esté contemplando a otros para reconstruir parches de seguridad parece irrazonable en la mayoría de los casos.

Estaba considerando implementar un sonar y un radar en los contenedores acoplables, pero saber que no recibirán las actualizaciones de seguridad regulares que recibe mi contenedor es un factor decisivo. Administrar actualizaciones de seguridad para mi contenedor es bastante complicado sin tener que lidiar de alguna manera con tener que aplicar manualmente las actualizaciones de seguridad a cada imagen de la ventana acoplable individualmente.