Skip to main content
Snyk Blog

In this article

Prenez des mesures pour améliorer la sécurité de vos images Docker

Écrit par
Headshot of Brian Vermeer

Brian Vermeer

William Henry

Docker report DARK

17 avril 2019

0 minutes de lecture

Bienvenue dans le rapport sur la sécurité Docker : Déplacer la sécurité Docker vers la gauche.Ce rapport se compose de plusieurs articles :

Vous pouvez aussi télécharger notre rapport PDF soigneusement élaboré, qui rassemble toutes ces informations et bien plus encore au même endroit :

Vous pouvez aussi télécharger notre rapport PDF soigneusement élaboré, qui rassemble toutes ces informations et bien plus encore au même endroit.

Choisir la bonne image de base

Une approche courante consiste à utiliser deux types d’images de base : l’une pour le développement et les tests unitaires, l’autre pour les tests ultérieurs et la production. Pour ces dernières étapes et la production, votre image n’a pas besoin d’outils de compilation tels que des compilateurs (par exemple, Javac), des systèmes de build (comme Maven) ou des outils de débogage. En production, votre image peut même ne pas avoir besoin de Bash.

Nous constatons des différences considérables entre les images de systèmes d’exploitation de base et leurs différentes variantes. La plupart du temps, une image complète de système d’exploitation n’est pas nécessaire. Des outils de création d’images comme Buildah permettent de créer des images à partir de zéro et d’installer uniquement les paquets nécessaires, ainsi que leurs dépendances. Cela réduit considérablement la surface d’attaque des images. Pensez à une image d’application Python qui ne contient que le paquet Python, ses dépendances et l’application Python.

Buildah présente également l’avantage de ne pas nécessiter le processus démon Docker. C’est important dans les plateformes de déploiement de conteneurs à grande échelle qui partagent les ressources utilisées pour créer les images. Le démon Docker est un processus privilégié qui expose un socket ouvert permettant de communiquer avec lui. Si le démon Docker est compromis, le nœud l’est aussi, ce qui peut souvent entraîner la compromission de tout un cluster. L’isolation explicite des nœuds de build ou l’utilisation d’un outil comme Buildah élimine le besoin d’un démon Docker.

Choisir une version allégée ou une autre implémentation d’une distribution Linux peut contribuer à réduire le nombre de vulnérabilités. Lorsque nous analysons l’image de base Alpine, une image Docker minimale de 5 Mo basée sur Alpine Linux, nous ne détectons aucune vulnérabilité connue. Toutefois, cela s’explique en grande partie par le fait que le projet Alpine ne tient pas de programme d’avis de sécurité : même si des vulnérabilités sont présentes, aucun avis officiel ne peut les signaler. Alpine reste néanmoins un bon exemple d’image de base très minimale et allégée sur laquelle construire.

Aucune vulnérabilité n’a été détectée dans la version de l’image Alpine que nous avons testée, mais cela ne signifie pas nécessairement qu’elle est exempte de problèmes de sécurité. Alpine Linux gère les vulnérabilités différemment des autres grandes distributions, qui préfèrent rétroporter des ensembles de correctifs. Alpine privilégie des cycles de publication rapides pour ses images, chaque nouvelle version incluant une mise à niveau des bibliothèques système.

Graphique à barres intitulé « Vulnérabilités dans les images de système d’exploitation » : Debian 55, Debian stretch-slim 42, Ubuntu 31, CentOS 1, Fedora 0 et Alpine 0.

Comme vous pouvez le voir sur le graphique ci-dessus, modifier l’image de base dans le Dockerfile ou simplement utiliser un autre tag d’une image standard peut faire une grande différence.

Lorsque vous créez votre propre image à partir d’un Dockerfile, veillez à ne pas dépendre d’images plus volumineuses que nécessaire. Vous réduirez ainsi la taille de votre image et limiterez le nombre de vulnérabilités introduites par vos dépendances.

Diagramme en barres intitulé « Vulnérabilités dans les images Node.js », indiquant 567 pour node:latest, 65 pour node:10-slim et 0 pour node:10-alpine.

D’après les analyses effectuées par les utilisateurs de Snyk, 44 % des images Docker analysées présentaient des vulnérabilités connues alors qu’il existait des images de base plus récentes et plus sûres. Ces conseils de remédiation sont propres à Snyk. Les développeurs peuvent prendre des mesures pour mettre à niveau leurs images Docker. Il est recommandé d’automatiser la recherche d’images de base plus récentes ou de meilleure qualité et de signaler leur disponibilité.

Utiliser des builds à plusieurs étapes

Les builds à plusieurs étapes sont disponibles avec Docker 17.05 et les versions ultérieures. Ils permettent de créer un Dockerfile optimisé, facile à lire et à maintenir.

Avec un build à plusieurs étapes, vous pouvez utiliser plusieurs images et sélectionner uniquement les artefacts nécessaires dans chacune d’elles. Vous pouvez utiliser plusieurs instructions FROM dans votre Dockerfile et choisir une image de base différente pour chacune, en copiant les artefacts d’une étape à l’autre. Vous pouvez laisser de côté les artefacts inutiles et obtenir malgré tout une image finale concise.

Cette méthode de création d’une image de petite taille réduit considérablement la complexité, mais aussi le risque d’inclure des artefacts vulnérables dans votre image. Au lieu de créer des images à partir d’autres images, elles-mêmes basées sur d’autres images, les builds à plusieurs étapes vous permettent de sélectionner les artefacts dont vous avez besoin sans hériter des vulnérabilités des images de base utilisées. Pour en savoir plus sur les builds à plusieurs étapes, consultez la documentation Docker.

Comme indiqué précédemment dans ce rapport, une autre approche consiste à utiliser des outils comme Buildah pour créer des images de production minimales ne contenant que les paquets nécessaires à l’exécution de votre application. Pour en savoir plus sur Buildah, consultez Buildah.io et Podman et Buildah pour les utilisateurs de Docker.

Reconstruire les images

Chaque image Docker est créée à partir d’un Dockerfile. Les Dockerfiles des images Docker disponibles sur Docker Hub sont accessibles au public sur GitHub. Un Dockerfile contient un ensemble d’instructions qui permet d’automatiser les étapes que vous effectueriez normalement manuellement pour créer une image. Il est également possible d’importer des bibliothèques et d’installer des logiciels personnalisés. Toutes ces instructions figurent dans le Dockerfile. Dans le rapport État de la sécurité de l’open source 2019, nous avons constaté que 20 % des images Docker vulnérables auraient pu être corrigées par une simple reconstruction.

La création d’une image revient essentiellement à prendre un instantané de celle-ci à un moment donné. Si vous utilisez une image de base sans tag précis, celle-ci peut changer à chaque reconstruction. L’installation de paquets à l’aide d’un gestionnaire de paquets peut également modifier l’image lors d’une reconstruction.

Un Dockerfile contenant les instructions suivantes peut produire un binaire différent à chaque reconstruction.FROM ubuntu:latestRUN apt-get -y update && apt-get install -y python

Toute image Docker doit être reconstruite régulièrement pour éviter les vulnérabilités connues qui ont déjà été corrigées. Lors de la reconstruction, utilisez l’option no-cache --no-cache pour éviter les résultats du cache et garantir un nouveau téléchargement.

Par exemple :docker build --no-cache -t myImage:myTag myPath/

En résumé, suivez ces bonnes pratiques lors de la reconstruction de votre image :

  • Chaque conteneur doit avoir une seule fonction.

  • Les conteneurs doivent être immuables, légers et rapides.

  • Ne stockez pas de données dans votre conteneur (utilisez un espace de stockage partagé).

  • Les conteneurs doivent pouvoir être facilement supprimés et reconstruits.

  • Utilisez une petite image de base (comme Linux Alpine). è Les images plus légères sont plus faciles à distribuer.

  • Évitez d’installer des paquets inutiles.

  • Votre image reste ainsi propre et sécurisée.

  • Évitez les résultats du cache lors du build.

  • Analysez automatiquement votre image avant le déploiement à l’aide d’un outil comme l’analyse de conteneurs de Snyk, afin d’éviter de déployer des conteneurs vulnérables en production.

  • Analysez quotidiennement vos images à la recherche de vulnérabilités, en développement comme en production. Automatisez ensuite leur reconstruction si nécessaire.

Analyser les images en développement

La création d’une image à partir d’un Dockerfile, et même sa reconstruction, peut introduire de nouvelles vulnérabilités dans votre système. Nous avons vu précédemment que 68 % des utilisateurs estiment que les développeurs ont une part de responsabilité importante dans la sécurité des conteneurs. L’analyse de vos images Docker pendant le développement doit faire partie de votre workflow afin de détecter les vulnérabilités le plus tôt possible.

Pour déplacer la sécurité vers la gauche, les développeurs devraient idéalement pouvoir analyser un Dockerfile et leurs images sur leur machine locale avant de les valider dans un dépôt ou un pipeline de build.

Cela ne signifie pas que vous devez remplacer les analyses du pipeline CI par des analyses locales. Il est préférable d’analyser à toutes les étapes du développement et, si possible, d’automatiser ces analyses.Pensez aux analyses automatisées pendant le build, avant l’envoi de l’image vers un registre, puis avant son déploiement en production. Il est recommandé de bloquer l’envoi d’une image vers un registre ou son déploiement en production si une analyse automatisée y détecte de nouvelles vulnérabilités.

La solution de gestion des vulnérabilités des conteneurs récemment lancée par Snyk analyse les images Docker en extrayant leurs couches et en examinant les informations des manifestes des gestionnaires de paquets. Nous comparons ensuite chaque paquet du système d’exploitation installé dans l’image à notre base de données des vulnérabilités Docker. Il est également essentiel d’analyser les principaux binaires installés dans les images. Snyk prend aussi en charge l’analyse des principaux binaires souvent installés autrement que par le gestionnaire de paquets du système d’exploitation (dpkg, RPM et APK), par exemple à l’aide d’une commande RUN.

En fournissant aux développeurs des outils pour analyser les Dockerfiles et les images sur leurs machines locales pendant le développement, vous ajoutez une couche de protection et leur permettez de contribuer activement à la sécurité globale du système.

Analyser les conteneurs en production

Il s’avère que 91 % des personnes interrogées n’analysent pas leurs images Docker en production. Vérifier activement vos conteneurs peut vous éviter bien des difficultés lorsqu’une nouvelle vulnérabilité est découverte et que votre système de production est potentiellement exposé.

Vous pouvez analyser régulièrement (par exemple, chaque jour) votre image Docker grâce aux fonctionnalités de surveillance des conteneurs de Snyk. Snyk crée un instantané des dépendances de l’image pour assurer une surveillance continue.

Vous devriez également activer la surveillance à l’exécution. L’analyse des modules et paquets inutilisés dans votre environnement d’exécution vous aide à réduire la taille des images. La suppression des composants inutilisés évite d’introduire des vulnérabilités superflues dans les bibliothèques système et applicatives. Elle facilite également la maintenance des images.

Pour aller plus loin :

Téléchargez le rapport maintenant !

Publié dans:
Sécurité des conteneurs