Question 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 conteneurs regroupent essentiellement les applications. et la plate-forme, quel est le moyen canonique de maintenir un système avec des conteneurs à jour? 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.


103
2017-07-08 21:54


origine


La meilleure idée que j'ai vue jusqu'à présent est Projet Atomic. Je ne pense pas que ce soit assez prêt pour prime time cependant. - Michael Hampton♦
Valko, avec quel flux de travail t'es-tu retrouvé? J'utilise des conteneurs à long terme (hébergeant php-cgi, par exemple) et ce que j'ai trouvé jusqu'à présent c'est: docker pull debian/jessie pour mettre à jour l'image, puis reconstruire mes images existantes, puis arrêter les conteneurs et les réexécuter (avec la nouvelle image). Les images que je construis ont le même nom que les précédentes, le démarrage se fait donc via le script. Je supprime ensuite les images "non nommées". J'apprécierais sûrement un meilleur flux de travail. - miha
miha: Cela ressemble à ce que j'ai fini par faire. Pratiquement continuellement mettre à jour et reconstruire toutes les images dans le cadre de la création de nouvelles versions. Et redémarrer les conteneurs en utilisant les nouvelles images. - Markus Hallmann
La meilleure réponse ici aide beaucoup car il y a un script qui contient les lignes de commande principales pour faire exactement ce que Johannes Ziemke a dit: - Hudson Santos


Réponses:


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.


43
2017-08-12 11:41



Merci, cela semble raisonnable. Vouloir simplement mettre à jour la plate-forme pour ainsi dire ne devrait pas déclencher le reconditionnement de l’application entière (par exemple, reconstruire 100 images d’application différentes en raison de la mise à jour d’une seule image de base). Mais peut-être est-ce inévitable avec la philosophie Docker consistant à tout regrouper dans une seule image. - Markus Hallmann
@ValkoSipuli Vous pouvez toujours écrire un script pour automatiser le processus. - dsljanus
Pourquoi pas apt-get upgrade, dnf upgrade, pacman -syu, etc. équivalent dans le conteneur? Vous pouvez même créer un script shell qui le fait et alors exécute l’application, puis l’utilise comme point d’entrée du conteneur afin que, lorsque le conteneur est démarré / redémarré, il mette à jour tous ses packages. - Arthur Kay
@ArthurKay Deux raisons: 1) Vous augmentez la taille du conteneur, car tous les packages mis à niveau seront ajoutés au calque conteneur tout en conservant le package obsolète dans l'image. 2) Il défait le plus gros avantage des images (conteneur): L’image que vous exécutez n’est pas la même que celle que vous construisez / testez car vous modifiez les packages à l’exécution. - Johannes 'fish' Ziemke
Il y a une chose que je ne comprends pas: si vous êtes une entreprise qui achète un logiciel livré en tant que conteneur docker, devez-vous attendre que le fabricant du logiciel reconstruise le package d'application chaque fois qu'un problème de sécurité survient ? Quelle entreprise abandonnerait ainsi le contrôle de ses vulnérabilités ouvertes? - Sentenza


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ée 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.


6
2017-10-03 19:44





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

SUSE / zypper-docker

Docker Quick Start


1
2018-05-08 17:05





Tout d’abord, bon nombre des mises à jour que vous avez traditionnellement exécutées dans le passé 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


0
2017-07-08 23:23