Comment gérer les mises à jour de sécurité dans les conteneurs Docker?

Lors du déploiement d'applications sur des serveurs, il existe généralement une séparation entre ce que l'application intègre avec elle-même et ce qu'elle attend de la plate-forme (système d'exploitation et packages installés) à fournir. L'un des avantages de cette solution est que la plate-forme peut être mise à jour indépendamment de l'application. Ceci est utile par exemple lorsque des mises à jour de sécurité doivent être appliquées de manière urgente aux packages fournis par la plate-forme sans reconstruire l'ensemble de l'application.

Traditionnellement, les mises à jour de sécurité étaient appliquées simplement en exécutant une commande du gestionnaire de packages pour installer les versions mises à jour des packages sur le système d'exploitation (par exemple, "yum update" sur RHEL). Mais avec l'avènement de la technologie des conteneurs, telle que Docker, où les images de conteneur regroupent essentiellement l'application et la plate-forme, quel est le moyen canonique de maintenir à jour un système avec des conteneurs? L'hôte et les conteneurs ont leurs propres ensembles de paquets indépendants qui ont besoin d'être mis à jour et mis à jour sur l'hôte ne mettront à jour aucun paquet à l'intérieur des conteneurs. Avec la sortie de RHEL 7 où les conteneurs Docker sont particulièrement présentés, il serait intéressant de savoir quelle est la méthode recommandée par Redhat pour gérer les mises à jour de sécurité des conteneurs.

Réflexions sur quelques-unes des options:

• Laisser le gestionnaire de packages mettre à jour les packages sur l'hôte ne mettra pas à jour les packages à l'intérieur des conteneurs.
• Le fait de devoir régénérer toutes les images de conteneur pour appliquer des mises à jour semble rompre la séparation entre l'application et la plate-forme (la mise à jour de la plate-forme nécessite un accès au processus de construction de l'application qui génère les images Docker).
• L'exécution de commandes manuelles dans chacun des conteneurs en cours semble fastidieuse et les modifications risquent d'être écrasées lors de la prochaine mise à jour des conteneurs à partir des artefacts de version de l'application.

Donc, aucune de ces approches ne semble satisfaisante.

Une application de bundle d'images Docker et une "plateforme", c'est exact. Mais généralement l'image est composée d'une image de base et de l'application réelle.

Ainsi, le moyen canonique de gérer les mises à jour de sécurité consiste à mettre à jour l'image de base, puis à reconstruire l'image de votre application.

Les conteneurs sont censés être légers et interchangeables. Si votre conteneur a un problème de sécurité, vous reconstruisez une version du conteneur corrigé et déployez le nouveau conteneur. (De nombreux conteneurs utilisent une image de base standard qui utilise des outils de gestion de paquets standard tels qu'apt-get pour installer leurs dépendances. La reconstruction extraira les mises à jour des référentiels.)

Bien que vous puissiez patcher à l'intérieur des conteneurs, cela ne va pas bien évoluer.

Ceci est géré automatiquement dans SUSE Enterprise Linux à l’aide de zypper-docker (1).

SUSE / zypper-docker

Docker Quick Start

Tout d’abord, nombre de vos mises à jour que vous avez traditionnellement exécutées ne seront tout simplement pas à l’intérieur du conteneur. Le conteneur doit être un sous-ensemble assez léger et petit du système de fichiers complet que vous avez l'habitude de voir dans le passé. Les packages que vous devez mettre à jour sont ceux qui font partie de votre fichier DockerFile. Etant donné que vous disposez du fichier DockerFile, vous devriez pouvoir suivre les paquets et les ID de conteneur nécessitant des mises à jour. L’interface utilisateur de Cloudstein, qui sera publiée prochainement, garde trace de ces ingrédients de DockerFile pour vous, afin que vous puissiez créer le schéma de mise à jour le mieux adapté à leurs conteneurs. J'espère que cela t'aides

c'est généralement pire que les trois choix que vous avez fournis. La plupart des images de docker ne sont pas construites avec des gestionnaires de paquets, vous ne pouvez donc pas simplement shell dans l'image de docker et émettre une mise à jour. Vous devrez soit reconstruire, soit récupérer l’image du menu fixe.

Le fait que vous ayez besoin de reconstruire ou que vous fassiez confiance à d'autres pour reconstruire des correctifs de sécurité semble déraisonnable dans la plupart des cas.

J'envisageais de déployer sonarr et radarr dans des conteneurs Docker, mais le fait de savoir qu'ils n'obtiendraient pas les mises à jour de sécurité régulières fournies à mon conteneur est un facteur décisif. La gestion des mises à jour de sécurité pour mon conteneur est assez fastidieuse sans avoir à appliquer manuellement des mises à jour de sécurité à chaque image de menu fixe.