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

117

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.

linux security redhat docker containers Markus Hallmann
la source
1
La meilleure idée que j'ai vue jusqu'ici est le projet Atomic . Je ne pense pas que ce soit tout à fait prêt pour le prime time cependant.
Michael Hampton
1
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/jessiemettre à 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
1
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
1
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
Question interessante. Je m'interroge moi-même. Si vous avez 20 applications s'exécutant sur un hôte de menu fixe, vous devez mettre à niveau les images de base, reconstruire et redémarrer! 20 applications et vous ne savez même pas si la mise à jour de sécurité les concerne toutes, ou une seule d'entre elles. Vous devez reconstruire l'image pour dire Apache lorsque la mise à jour de sécurité concerne uniquement libpng par exemple. Donc, vous vous retrouvez avec des reconstructions inutiles et des redémarrages ...
Dalibor Filus

Réponses:

47

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.

Le poisson de Johannes Ziemke
la source
3
Merci, cela semble raisonnable. Je souhaite toujours simplement mettre à jour la plate-forme pour ainsi dire, sans avoir à 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 c'est peut-être inévitable avec la philosophie Docker consistant à tout regrouper dans une seule image.
Markus Hallmann
3
@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 faisant cela , puis exécuter l'application, puis l'utiliser comme point d'entrée du conteneur afin que, lorsque le conteneur est démarré / redémarré, il mette à niveau tous ses packages.
Arthur Kay
8
@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 vous construisez / testez parce que vous modifiez les packages à l’exécution.
Le poisson de Johannes 'Ziemke le
7
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
7

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.

Paul R
la source
0

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

Ben Grissinger
la source
-1

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.

Lee Burch
la source
1
Votre message ne serait pas considéré comme une réponse, car vous ne fournissez pas de réponse à la question. Ajoutez-le comme commentaire à la question et supprimez votre "réponse". StackExchange n'est pas un forum, mais devrait être considéré comme un Q & R où les experts répondent à des questions pour lesquelles ils peuvent fournir de l'aide.
Phillip -Zyan K Lee- Stockmann