Sécurisation des images Docker

Une image Docker est constituée d'une pile de couches, qui sont des ensembles immuables et en lecture seule de modifications du système de fichiers, superposées les unes aux autres. Le système d'exploitation de base se trouve tout en bas, suivi des paquets dont il a besoin pour fonctionner, puis de votre propre code par-dessus. Sécuriser les images Docker consiste à contrôler leur contenu et à veiller à ce qu'elles soient mises à jour après leur déploiement.

La plupart des vulnérabilités d’un conteneur proviennent des paquets et bibliothèques open source dont il est équipé. Certaines, comme cURL ou un shell, ne seront peut-être jamais appelées par votre application une fois le conteneur en cours d’exécution ; elles peuvent donc être supprimées de l’image. D’autres, comme glibc, sont indispensables au fonctionnement de votre application et ne peuvent pas être supprimées. Le reste des vulnérabilités résulte généralement d’une erreur humaine, comme un secret intégré dans une couche ou un conteneur laissé en cours d’exécution avec des privilèges root.

Cet article explique d'où proviennent les risques liés à une image Docker, en quoi le renforcement de la sécurité des images relève d'un problème d'gestion des vulnérabilités , présente les trois méthodes utilisées par les outils pour maintenir à jour une image de base, et décrit comment Aikido renforce la sécurité et met à jour les images que vous utilisez déjà.

{{cta}}

TL;DR

Pour sécuriser les images Docker, il faut supprimer les paquets inutilisés et corriger les vulnérabilités dans ce qui reste. Le fait de supprimer les paquets inutilisés ne permet d’éliminer que les vulnérabilités présentes dans les éléments dont vous n’avez pas besoin. Un paquet vulnérable dont votre application dépend réellement doit tout de même être corrigé, et même une image allégée continue d’accumuler de nouvelles vulnérabilités. De plus, l’adoption d’images renforcées implique souvent de migrer vers une autre distribution et de se mettre à jour selon le rythme imposé par un tiers. Aikido fournit de nouvelles versions corrigées des mêmes images de base, disponibles via PR. Si vous avez fixé une version, cela vous permet de rester sur cette version, sans subir de changements incompatibles ni devoir passer à une nouvelle image.

D'où provient le risque lié à une image Docker ? 

Le FROM Cette ligne correspond à la première instruction d'un fichier Dockerfile ; elle désigne l'image de base sur laquelle vous allez construire votre image. Une À partir du nœud : 24 utilise comme base l'image officielle Node.js 24, qui intègre le moteur d'exécution Node.js ainsi qu'un système Debian complet. Cela comprend un shell, un gestionnaire de paquets et des bibliothèques système, qui peuvent tous comporter des vulnérabilités dont vous héritez avant même d'avoir écrit la moindre ligne de code.

Chaque instruction du fichier Dockerfile ajoute une couche par-dessus la précédente, et ces couches sont immuables. Supprimer un élément dans une couche ultérieure ne fait que le masquer ; ainsi, tout ce qui est inclus dans la base reste dans l'image, que votre application l'utilise ou non. Votre application n'utilise jamais la plupart des éléments fournis dans la base, mais chaque paquet qui s'y trouve constitue une surface d'attaque.

Par exemple, la vulnérabilité CVE-2023-4911 (« Looney Tunables ») était une faille permettant l'élévation locale des privilèges dans le chargeur dynamique de glibc, un composant présent dans la couche de base de presque toutes les images Linux courantes. glibc était fournie avec la distribution, et tout conteneur construit à partir d'une base affectée en était affecté. 

Des bases différentes, des risques différents

Toutes les images de base ne contiennent pas la même quantité de données. Une image de distribution complète contient bien plus que ce dont votre application a besoin, notamment un shell et un gestionnaire de paquets qu’elle n’utilisera probablement jamais. Une variante allégée en supprime une partie. Une image « distroless » supprime entièrement le shell et le gestionnaire de paquets et ne conserve que ce dont l’environnement d’exécution a besoin. Alpine est petite par conception et, comme elle repose sur musl plutôt que sur glibc, elle n’a même pas été exposée aux « Looney Tunables ».

Le maintien de la sécurité des images est un problème lié à l'gestion des vulnérabilités

Une image figée est propre le jour où vous la créez, mais elle se dégrade avec le temps, à mesure que de nouvelles vulnérabilités sont découvertes dans les paquets qu’elle contient déjà. Pour garantir sa sécurité, il faut considérer cette image comme un élément qu’il faut vérifier régulièrement à la lumière des nouvelles vulnérabilités divulguées et pour lequel il faut appliquer les correctifs de manière continue. La méthode manuelle consiste à suivre les vulnérabilités divulguées pour chaque paquet de chaque base et à appliquer manuellement chaque correctif (en effectuant un backport ou en mettant à jour la version).

Le verrouillage sur une version fiable est judicieux lorsque vous avez réellement testé cette version et que vous souhaitez continuer à l’utiliser, mais vous devez tout de même rester à l’affût des nouvelles vulnérabilités révélées. Une image verrouillée puis oubliée accumulera les vulnérabilités nouvellement découvertes. Si cette image atteint sa fin de vie et ne reçoit plus de correctifs de la part de l’éditeur en amont, la liste de ses failles connues et non corrigées ne cesse de s’allonger. Par exemple, Node.js 20 a atteint sa fin de vie le 30 avril 2026 ; ainsi, un conteneur toujours fixé sur « node:20 » continuera de fonctionner, mais toutes les vulnérabilités révélées depuis lors concernant cette version resteront non corrigées, sans qu’aucun correctif ne soit prévu.

L'instinct inverse, qui consiste à se précipiter systématiquement sur la toute dernière version, est tout aussi erroné. Par exemple, la faille « xz-utils » est une bibliothèque de compression intégrée à la plupart des images de base Linux. Elle était présente dans deux versions récentes spécifiques, la 5.6.0 et la 5.6.1, tandis que les équipes utilisant encore l'ancienne version 5.4 n'ont jamais été exposées au risque. Les recommandations émises par la CISA par la suite consistaient à revenir à une version antérieure, et non à effectuer une mise à jour. 

Ce qui garantit votre sécurité, c’est de prendre des décisions mûrement réfléchies concernant les versions que vous utilisez. Prenons l’exemple d’une équipe qui fixe la version « debian:bookworm », qui indique avoir préféré cette version à la dernière en date parce qu’elle l’a testée et qu’elle est stable, et qui la compare aux nouvelles vulnérabilités au fur et à mesure qu’elles sont révélées. Lorsqu’une nouvelle vulnérabilité CVE est signalée sur un paquet de cette image, l’équipe sait déjà qu’elle l’utilise et pourquoi. Cela lui permet d’évaluer le risque réel par rapport au coût d’une mise à jour.

Comment sécuriser les images Docker

Réduire la surface d'attaque

Commencez par une image de base minimale ou pré-sécurisée. C'est l'image de base qui détermine en grande partie ce dont vous héritez ; il s'agit donc du choix le plus déterminant que vous ferez. (Ce sujet sera abordé plus en détail dans la section suivante.)

Utilisez des builds en plusieurs étapes pour éviter que les outils de build ne se retrouvent dans l’image finale. Le build de l’image intègre généralement un compilateur, des en-têtes de développement et un gestionnaire de paquets pour compiler votre application et installer ses dépendances. Dans une compilation en une seule étape, tous ces éléments restent intégrés à l'image finale, même si l'application en cours d'exécution ne les utilise jamais. Une compilation en plusieurs étapes produit l'artefact lors d'une étape préliminaire et ne copie que celui-ci dans une étape finale « propre », de sorte qu'aucun des outils de compilation n'est livré.

Supprimez les paquets dont l'application en cours d'exécution n'a pas besoin. Vous n'avez probablement pas besoin d'un shell, car la plupart des applications lancent directement leur processus et n'en appellent jamais un lors de l'exécution. Des utilitaires comme cURL ou wget sont utiles lors de la compilation, mais vous n'en avez probablement pas besoin lors de l'exécution, puisque votre application effectue ses appels réseau via ses propres bibliothèques. Et tout ce que cURL a récupéré pendant la compilation est déjà intégré à l'image au moment de sa livraison ; il n'y a donc plus rien à télécharger. 

Configurer correctement les autorisations

Exécutez le conteneur en tant qu’utilisateur non-root. Si un pirate parvient à exécuter du code dans votre application, il disposera des mêmes privilèges que ceux dont bénéficie le conteneur. L’utilisation d’un compte non-root limite l’ampleur des dégâts en cas d’intrusion.

Utilisez un système de fichiers racine en lecture seule. Cela empêche un attaquant déjà présent dans le système d'écrire des fichiers, d'y implanter des outils ou de modifier le conteneur pendant son exécution. Tout ce qui nécessite réellement d'écrire peut bénéficier à la place d'un montage spécifique en écriture.

Supprimez les capacités Linux que vous n'utilisez pas. Les conteneurs démarrent avec un ensemble de capacités du noyau que la plupart des applications n'utilisent jamais. CAP_NET_RAW, par exemple, permet à un processus de falsifier des paquets réseau et est activée par défaut, mais une application web classique n'en a jamais besoin, alors qu'un attaquant qui parviendrait à s'introduire pourrait l'utiliser pour usurper le trafic sur votre réseau. Désactivez celles dont vous n'avez pas besoin et ne réactivez que celles qui vous sont utiles. La désactivation de ces fonctionnalités (et la réactivation uniquement de celles dont vous avez besoin) empêche un attaquant d'accéder à des opérations privilégiées dont il disposerait autrement.

Veillez à ce qu'aucun secret ni fichier indésirable ne figure dans l'image

Évitez d'intégrer des secrets dans les couches. Un secret importé via ARG ou COPIER reste dans l'historique de l'image même si un calque créé par la suite le supprime, et toute personne qui récupère l'image peut décompresser les calques et le consulter. Utilisez montures secrètes ou Montages SSH pour révéler un secret au cours d'une seule étape de compilation sans l'enregistrer dans une couche.

Garder un secret hors des couches ne représente que la moitié du travail. Le conteneur en exécution a toujours besoin de cette valeur ; il faut donc l’injecter au moment de l’exécution à partir d’un gestionnaire de secrets dédié (Vault, un gestionnaire de secrets « cloud » ou les secrets Kubernetes) monté en tant que fichier ou injecté dans l’environnement, et la renouveler selon un calendrier défini, plutôt que d’intégrer de manière permanente des identifiants à longue durée de vie où que ce soit.

Utilisez un .dockerignore fichier. Il détermine ce qui est intégré au contexte de compilation dès le départ, donc .git, la configuration locale et les identifiants isolés ne sont jamais copiés dans l'image par une opération générale COPIER instruction.

Épinglez avec précaution

Épinglez la base à l'aide d'une épingle à tête plate, et non d'une épingle à tête ronde. À partir du nœud : 24 se met à jour au fil du temps ; ainsi, deux versions compilées à un mois d’intervalle peuvent récupérer des images différentes, et une base compromise peut s’y glisser à l’insu de tous. Fixation par digest (@sha256 :...) rend la base déterministe, ce qui vous permet de créer exactement l’image que vous avez testée. Sachez toutefois que si votre modèle de correctifs fournit les correctifs sous forme de nouvelles images, un digest figé bloque également ces correctifs. Si, en revanche, vous pouvez obtenir une version corrigée de la même version que celle que vous avez figée, vous évitez ce problème et préservez la sécurité.

Ne vous fiez pas à « latest ». Certains pensent que cela désigne la version la plus récente et la plus stable, mais dans Docker, il s'agit simplement de l'étiquette par défaut appliquée à la dernière image publiée sans balise de version explicite. Elle peut renvoyer à une image plus ancienne que prévu et peut changer d'une compilation à l'autre.

Vérifier et entretenir

Générer un SBOM pour chaque image. Un fichier « software bill of materials » répertorie l'intégralité du contenu de l'image, avec tous les paquets et leurs versions. C'est ce qui vous permet de répondre à la question « Sommes-nous concernés ? » dès qu'une nouvelle vulnérabilité est signalée. 

Signez chaque image une fois qu'elle est créée, puis vérifiez cette signature avant son exécution à l'aide d'un contrôleur d'accès qui rejette tout élément non signé. Ce processus empêche toute image altérée ou non approuvée d'atteindre l'environnement de production, même si quelqu'un parvient à accéder à votre registre.

Considérez les conteneurs en cours d'exécution comme immuables. Une fois qu'une image est déployée, n'appliquez pas de correctifs et ne reconfigurez pas le conteneur en cours d'exécution. Créez une nouvelle image, testez-la, puis redéployez-la. Ce qui s'exécute correspondra alors toujours à ce que vous avez créé, testé et signé, ce qui élimine toute dérive de configuration et rend la restauration aussi simple que le redéploiement de l'image précédente.

Vérifiez régulièrement les images. Une image qui avait été validée la semaine dernière peut présenter aujourd'hui une vulnérabilité critique, car de nouvelles vulnérabilités sont révélées chaque jour concernant des paquets qu'elle contient déjà. La vérification au moment de la compilation n'est donc pas suffisante. 

Trois façons de maintenir une image de base sécurisée

Maintenir une image de base sécurisée à mesure que de nouvelles vulnérabilités sont découvertes est une tâche permanente, et il existe trois façons de s'y prendre.

Faites-le vous-même

Maintenez votre propre base sécurisée. Choisissez une image minimale, supprimez ce dont vous n'avez pas besoin et reconstruisez-la chaque fois qu'un paquet qu'elle contient présente une vulnérabilité. Vous gardez ainsi un contrôle total, mais cela nécessite un travail et une maintenance continus. Vous devez suivre les divulgations concernant chaque paquet de la base et effectuer manuellement le backport ou la mise à jour de chaque correctif. Multipliez cela par chaque base de chaque service, et cela vous empêche de vous consacrer à tout ce que vous pourriez développer d'autre.

Passer à la distribution remaniée d'un fournisseur

Certaines plateformes fournissent des images sécurisées, reconstruites à partir de leur propre distribution. Vous migrez vos services vers leur base, vous effectuez de nouveaux tests pour détecter d’éventuelles défaillances, puis vous suivez leur rythme de publication, en passant à une nouvelle version à chaque correction. Cela entraîne deux inconvénients. La migration elle-même peut causer des dysfonctionnements dans tout ce sur quoi votre application s'appuyait et que le fournisseur a supprimé. Et rester à jour implique le même piège de mise à niveau que celui rencontré lors de toute mise à niveau de dépendance : une nouvelle version majeure peut déplacer les chemins d’accès aux paquets, modifier les valeurs par défaut et rendre inopérant un Dockerfile qui fonctionnait auparavant. Si vous fixez un digest pour des raisons de stabilité, vous ne bénéficiez pas des correctifs pour lesquels vous avez adopté l’outil.

Laissez un outil corriger la version de base que vous utilisez déjà

Certains fournisseurs vous permettent de conserver votre version actuelle en proposant des versions corrigées de la même version, plutôt que de passer à une nouvelle image. Vous recevez ainsi une nouvelle version de la même version, dans laquelle la vulnérabilité CVE a été corrigée, que vous adoptez en la vérifiant et en la fusionnant comme n'importe quelle autre modification, sans avoir à modifier l'image en cours d'exécution. De cette manière, vous conservez la version que vous avez déjà testée tout en corrigeant la vulnérabilité.

Comment « Aikido » sécurise les images Docker

Aikido Le service de sécurité fournit de nouvelles versions corrigées des images de base que vous utilisez déjà.

Aikido Images est un référentiel regroupant plus de 2 000 images prêtes à l'emploi, dans lesquelles les vulnérabilités critiques et à haut niveau de gravité connues du système de base ont déjà été corrigées. Chacune d'entre elles est recompilée, corrigée, allégée et renforcée lors de la compilation, ce qui vous permet de bénéficier d'une surface d'attaque réduite et de paramètres par défaut verrouillés sur le système de base que vous utilisez déjà.

Alors qu’un outil de distribution reconstruite fournit le correctif sous la forme d’une nouvelle image vers laquelle vous migrez, Aikido effectue un backport du correctif vers la version que vous avez figée. Il récupère le correctif de la version la plus récente et l’applique à la version que vous utilisez déjà, de sorte que la modification reste minime et que l’image continue de fonctionner comme avant. Lorsqu’un backport propre n’est pas possible, Aikido procède alors à la mise à jour ou à la reconstruction du composant. Le remplacement est une solution prête à l’emploi qu’AutoFix propose sous forme de pull request, et chaque pull provenant de docker.aikido.io est accompagné d’une traçabilité via l’ SBOM, VEX et SLSA.

Il continue à corriger les versions même après que le développeur d'origine soit passé à autre chose, y compris les versions de base qui ont atteint leur fin de vie. Vous pouvez ainsi conserver une version plus ancienne sans en subir les failles connues, et vous n'êtes pas obligé de mettre à jour simplement pour rester protégé.

Une part croissante des correctifs réels apportés aux paquets ne se voit jamais attribuer de numéro CVE ; par conséquent, si vous ou vos outils vous contentez de consulter la base de données CVE, vous passez à côté de certaines vulnérabilités. Le système de correctifs de Aikido s'appuie en partie sur Aikido Intel, qui analyse les journaux de modifications et l'historique des commits en amont afin de détecter les vulnérabilités qui ont été discrètement corrigées en amont sans qu'un numéro CVE ne leur soit attribué ; ainsi, la couverture ne se limite pas à ce que les bases de données publiques ont eu le temps d'enrichir.

Les paquets au niveau des applications sur npm, PyPI, Maven et Go sont corrigés directement via les bibliothèques «Aikido », en utilisant la même approche de rétroportage que celle appliquée à vos dépendances. De plus, Aikido analyse d’images de conteneurs effectue des vérifications visant à détecter les paquets du système d’exploitation vulnérables, les dépendances, les environnements d’exécution obsolètes, les logiciels malveillants et les risques liés aux licences dans les images de base, les commandes Dockerfile et les charges de travail Kubernetes, de sorte qu’une anomalie s’affiche avec le code et le contexte d’ cloud .

L'équipe à l'origine de ces images a rejoint Aikido suite à l'acquisition de Root, la société créatrice de SlimToolkit (anciennement DockerSlim), l'un des outils open source les plus utilisés pour le renforcement de la sécurité des images. C'est par le renforcement de la sécurité des images que cette équipe a fait ses débuts, et cet outil reste gratuit et accessible à tous.

{{walkthrough}}

FAQ