Analyser la sécurité d’une image Docker : les risques, les outils et les bonnes pratiques
Sommaire
I. Présentation
Dans cet article, nous allons explorer différentes méthodes et outils pour vérifier et analyser la sécurité d’une image Docker avant de l’intégrer dans notre système d’information ou notre projet.
Les images et les conteneurs Docker offrent l’avantage d’être faciles et rapides à utiliser. Avec la conteneurisation désormais omniprésente dans les systèmes d’information, il est fortement conseiller de se pencher sur la sécurité des éléments que nous y intégrons.
En effet, plus il est rapide de déployer un composant au sein d’un système d’information, plus le risque de négligence ou d’erreur pouvant mener à une vulnérabilité ou à la compromission du SI est élevé. Il est donc crucial d’avoir les bons réflexes, mais aussi les bons outils, pour évaluer rapidement si l’image Docker que nous souhaitons utiliser est conforme aux bonnes pratiques de sécurité.
Pour rappel, une image Docker est différente d’un conteneur Docker. L’image est un modèle qui permet de déployer (ou instancier) un ou plusieurs conteneurs Docker. Cela permet d'utiliser et de modifier les conteneurs sans altérer l’image, qui reste elle intacte. Il est donc primordial de vérifier la sécurité de l’image, puisqu’elle servira de modèle à tous les conteneurs basés sur celle-ci.
Dans cet article, nous nous concentrerons donc sur l'analyse d'une Image Docker, et non d'un conteneur Docker en cours d'exécution.
Par soucis de lisibilité, je ne détaillerai pas ici toute la procédure d’installation des outils que je vais citer. Je vous renverrai aux documentations officielles, qui sont très claires. Il n’y aura rien qui sort de l’ordinaire en termes de procédure d’installation.
II. Quels sont les risques liés aux images Docker ?
Concrètement, quels sont les risques d’utiliser une image Docker sans avoir vérifié au préalable quelques détails importants ? C’est ce que nous allons voir dans ce chapitre.
A. Utilisation d’une image piégée
Il ne faut pas oublier que les images Docker sont des éléments externes qui sont intégrés au système d’information pour ensuite exécuter des tâches, manipuler des données, émettre et recevoir des paquets vers l’extérieur.
Comme tout élément de ce type (on pense notamment aux exécutables), ils peuvent être utilisés par les attaquants pour compromettre un système d’information sans trop d’effort. Il existe aujourd’hui une guerre de l’ombre entre les plateformes qui mettent à disposition des images Docker (Docker Hub bien sûr, mais également GitHub) et les attaquants. Ces derniers utilisent très fréquemment l’image Docker comme vecteur d’infection, une simple typo d'un "docker pull" ou négligence peut suffire à introduire une image backdooré (contenant une porte dérobée) chez la victime ou effectuer des calculs de minage (cryptominer) visant à rapporter de l'argent pour le compte de l'attaquant.
En mai 2024, nous vous rapportions que d’après les recherches des chercheurs en sécurité de chez JFrog, 20% des dépôts hébergés sur Docker Hub contenait du contenu malveillant :
B. Utilisation d’une image obsolète et vulnérable
Également, dans la mesure où une image Docker intègre des paquets, avec des versions spécifiques et une exposition sur le réseau. Il peut lui aussi être insuffisamment durcie par rapport aux bonnes pratiques de sécurité (défaut de configuration), voir avoir des manques importants de mise à jour.
En voulant aller vite pour déployer une infrastructure, il peut donc arriver que l’on utilise une image Docker basée des versions obsolètes d’outils, commandes ou services qui y sont intégrés.
II. Utiliser des outils d'analyse statique
A. Hadolint – vérification du Dockerfile
Hadolint est un outil qui permet d’analyser le Dockerfile et vérifier qu'il respecte les bonnes pratiques de sécurité recommandées par Docker. Il permet de détecter des erreurs courantes comme l'installation de paquets inutiles, l'utilisation de l'utilisateur root, etc.
Dans l’environnement Docker, le Dockerfile est un fichier qui permet de construire l’image Docker. Voyez cela comme une procédure qui permet d’indiquer à Docker comment précisément créer l’image, en spécifiant, par exemple, une autre image source, les dépendances et les paquets à installer, les ports réseau à exposer par défaut, les commandes à exécuter, etc.
Dans la plupart des cas, les Dockerfiles peuvent être trouvés rapidement, ils n’ont pas un caractère secret. Les Dockerfiles peuvent d'ailleurs être utilisés par l'utilisateur final afin de construire lui-même l'image voulue, c'est donc un fichier qui n'est en principe pas difficile à trouver (sinon, méfiance).
Images officielles
Pour les images "officielles" du Docker Hub (les plus utilisées), le Dockerfile est disponible dans les dépôts GitHub officiels du mainteneur. Par exemple, le Dockerfile de l'image officielle nginx se trouve ici :
Images de la communauté
Pour les images créées par la communauté, la disponibilité du Dockerfile dépend de l'auteur de l'image :
- Certains fournissent le Dockerfile directement sur la page de l'image Docker Hub.
- D'autres mettent à disposition un lien vers leur dépôt Github contenant le Dockerfile.
- Malheureusement, certains auteurs ne partagent pas leur Dockerfile, ce qui empêche de faire les vérifications voulues.
Pour installer hadolint, il suffit de télécharger le binaire compilé depuis la page Github du projet :
Une fois disponible, il est possible d’utiliser hadolint très facilement pour analyser un Dockerfile ayant servi à construire une image Docker :
./hadolint <Dockerfile>
Voici un exemple de retour que nous pouvons avoir :
Nous avons plusieurs informations remontées, qui sont essentiellement des points de non-conformité par rapport aux bonnes pratiques proposées par Docker lors de la construction d’un DockerFile. Toutes les règles (par exemple, ici "DL3009", "DL3015", etc) sont documentées sur le GitHub d’hadolint et possèdent des références vers la documentation GitHub associée pour mieux comprendre l’impact et leur raison d’être :
La façon dont l'image Docker que vous allez utiliser est construite est donc un premier élément important à vérifier.
B. Trivy - Analyse de sécurité d’une image Docker
Trivy est un scanner de vulnérabilités open source qui analyse les images Docker pour détecter les vulnérabilités connues (CVE) dans les systèmes d'exploitation et les packages. Il peut entre autres être utilisé en ligne de commande.
L'installation de trivy peut se faire via un simple "apt-get install" sous Linux. Le dépôt GitHub du projet propose plusieurs autres méthodes d'installation :
Il nous faut ensuite utiliser la commande "trivy image" suivi du nom de l'image à analyser :
$ trivy image python:3.4-alpine
2024-06-02T11:15:53+02:00 INFO Vulnerability scanning is enabled
2024-06-02T11:15:53+02:00 INFO Secret scanning is enabled
2024-06-02T11:15:59+02:00 INFO Detected OS family="alpine" version="3.9.2"
2024-06-02T11:15:59+02:00 INFO [alpine] Detecting vulnerabilities... os_version="3.9" repository="3.9" pkg_num=28
2024-06-02T11:15:59+02:00 INFO Number of language-specific files num=1
2024-06-02T11:15:59+02:00 INFO [python-pkg] Detecting vulnerabilities...
2024-06-02T11:15:59+02:00 WARN This OS version is no longer supported by the distribution family="alpine" version="3.9.2"
Le nom exact de l'image que l'on souhaite analyser peut-être trouvé directement sur le Docker Hub, il est également possible de spécifier une version précise, comme lors d'un "docker pull" :
Voici, par exemple, le résultat d’une analyse trivy sur une version non à jour de l'image Docker "python3:3.4-alpine" (cliquez sur l'image pour zoomer) :
Nous voyons ici que tous les paquets installés au sein de l'image ont été analysés. Trivy vérifie notamment à partir de leur version si ces paquets sont à jour ou concernés par des vulnérabilités publiques (avec un lien vers les CVE correspondantes). Parmi les autres éléments qui peuvent être remontés par Trivy figurent :
- la liste des packages intégrés à une image ;
- la découverte de secret et d’informations sensibles ;
- la présence de mauvaises configurations dans les fichiers IAC (Infrastructure as Code) utilisant Docker comme Kubernetes, Terraform, Azure ARM, Heml, etc ;
- des informations concernant les licences des packages utilisés.
Trivy est un outil très complet qui possède de nombreuses options et contextes d’utilisation. Cela sera surement le sujet d’un article qui lui sera dédié. Mais, il faut retenir qu’il permet de se faire un avis, notamment sur le niveau de mise à jour des paquets utilisés au sein de l’image. Ceux-ci possèdent un cycle de vie très différent de ceux de l’hôte sous-jacent et sont moins susceptibles d’être mise à jour, cela nécessitant le déploiement d’une nouvelle image.
C. Utilisation de Snyk pour l'analyse d'image Docker
Snyk est une entreprise spécialisée dans les solutions de développement sécurisé. Elle propose des outils permettant de vérifier la sécurité des dépendances logicielles utilisées dans divers langages de programmation. Snyk offre plusieurs solutions pour analyser et sécuriser des images Docker et des infrastructures basées sur Docker, notamment un outil en ligne de commande pour faciliter ces vérifications :
La sortie et les tests effectués vont dans le même sens que ceux présentés par trivy, cela nous permet dans mon exemple de constater la présence de vulnérabilités importantes dans l'image Docker analysée.
L'inconvénient de cette solution est qu'elle nécessite une authentification sur le service de Snyk, et qu'elle peut envoyer des informations de reporting sur le site web de Snyk pour une consultation du rapport via Web. Bien que le rapport puisse être assez agréable à parcourir ainsi, il faut être au courant de ce petit détail si la confidentialité est nécessaire dans votre contexte.
III. Analyser le contenu d'une image Docker avec Dive
Dive est un outil qui, bien qu'il ne soit pas spécifiquement dédié à la sécurité, permet de parcourir facilement et de manière graphique le contenu d'une image Docker (son système de fichiers) et d'explorer visuellement ses différentes couches (layer). Voyez plutôt :
# Utilisation de dive pour analyser une image Docker
dive <image>
# Exemple
dive postgres
La sortie standard de dive ressemble à celle-ci, il s'agit d'un tableau interactif contenant plusieurs sections (cliquez sur l'image pour zoomer) :
L'intérêt de dive, du point de vue de la sécurité, est sa capacité à permettre l'exploration des différentes couches qui composent une image Docker, ainsi que les modifications effectuées à chaque couche. Cette fonctionnalité est accessible via la section 1 (Layers).
Pour rappel, une image Docker est composée de plusieurs couches superposées. Chaque couche représente un ensemble de modifications apportées à l'image de base. En partant d'une image alpine, une couche peut ajouter des fichiers, une deuxième installer des logiciels (par exemple : Python3.10), une troisième configurer des paramètres système (la variable "PATH"). Les couches sont empilées les unes sur les autres pour former l'image finale.
Pour chaque couche, dive fournit le détail des modifications effectuées dans la section 2 (Layer Details) et l'impact de ces modifications sur le système de fichier dans la section 4 (Current Layer Contents).
Dans les faits, dive utilise des informations qui sont récupérables dans l'image Docker ainsi que par des commandes natives comme "docker history" :
Cependant, la vue qu'il propose permet de bien mieux comprendre l'impact de chaque couche ayant permis de construire l'image analysée. Ces informations sont également visibles facilement au sein du Docker Hub (par exemple ici) , mais il faut également savoir réaliser l'opération soit même, notamment si l'on utilise des images ne venant pas du Docker Hub ou mal documentées.
Vous l'aurez compris, l'idée est de comprendre en détail les actions effectuées lors de la construction de l'image, et d'identifier de potentielles actions malveillantes ou anormales. Cela pour se protéger des images contenant des éléments malveillants, voire des défauts évident de configuration.
IV. Bonnes pratiques d’administration Docker
A. Utiliser un registre d'images officiel
Lorsque l'on conçoit une infrastructure basée sur Docker, que cela soit pour un simple test ou un grand projet, il est important de se baser sur des images approuvées et vérifiées. Il est toujours préférable d'utiliser un registre d'image officiel par rapport à une image ou un DockerFile que l'on pourrait trouver sur d'autres sources (site web, GitHub, lien bizarre transmis par mail...), dans la mesure où ceux-ci disposent d'informations permettant de se faire une idée du sérieux d'une image par rapport à une autre (nombre de téléchargements, date de dernière mise à jour, etc.).
- Le registre officiel de Docker est le Docker Hub.
Toutefois, au sein du Docker Hub, tout le monde peut publier des images (comme sur PyPi pour les librairies Python ou GitHub pour le code). Il est donc nécessaire de savoir distinguer l'image "attacker/nginx" (image nommée "nginx" de l'utilisateur "attacker") et l'image officielle de l'éditeur "nginx" (officielle, mise à disposition par Docker). Même si Docker fait souvent le ménage parmi les images malveillantes qui pourraient s'y trouver.
Également, si vous cherchez "nginx" sur le Docker Hub, vous obtenez des milliers de résultats, répartis sur des dizaines de pages :
Les différents badges pointés dans l'image ci-dessus vous permettent d'être un peu plus sûr que ces images ne contiennent pas de contenu malveillant (elles ne sont pas pour autant à jour, les paquets obsolètes qu'elles contiennent peuvent contenir des vulnérabilités) :
- Docker Official Image : images créées en partenariat entre des développeurs, volontaires de la communauté Docker et Docker. Elles servent notamment de base à bon nombre d'images. On y retrouve, par exemple, Alpine, Ubuntu, Nginx, etc.
- Verified Published : il s'agit d'éditeurs d'image qui ont été vérifiés et approuvés par Docker
- Sponsored OSS (Docker sponsored Open Source Software) : il s'agit de projets open-source sponsorisés par Docker.
Une bonne pratique à respecter est donc de se restreindre autant que possible aux images venant d'éditeurs vérifiés. Encore une fois, il faut être vigilant, l'éditeur peut mettre à jour quelques lignes de configuration au sein de son image, sans pour autant se soucier de la mise à jour des paquets qu'il utilise !
B. Maitriser la technologie et les scénarios d’attaque
En plus de maitriser les outils basiques permettant d’analyser la sécurité d’une image Docker, il est important de maitriser la technologie Docker elle-même et d’en comprendre le fonctionnement précis. Cela vous évitera bien des problèmes et des négligences, en commençant par ne pas copier-coller des commandes venant de sites web sans comprendre précisément ce qu'elles font, ou de réutiliser des images Docker peu fiables.
Veillez donc à avoir un niveau de formation correspondant aux implications de vos actions en termes de sécurité. De très bonnes formations gratuites existent sur le sujet.
Également, il est important de savoir quelles sont les vulnérabilités et vecteurs d’attaque courant autour de l’environnement Docker, cela pour acquérir les bons réflexes et comprendre pourquoi telle information, configuration ou détail est important d’un point de vue sécurité.
- Je vous oriente pour cela sur la matrice du MITRE : ATT&CK Containers
Celle-ci liste les vecteurs d’attaque observés dans des cyberattaques réelles autour de l’environnement Docker :
En parcourant ces différentes attaques et techniques, vous aurez une meilleure idée d'où peuvent venir les attaquants et quelles faiblesses ils peuvent exploiter. Cela vous permettra également d'identifier les éléments pertinents d'un point de vue sécurité lors de l'analyse d'une image Docker.
V. Conclusion
Nous avons vu dans cet article quelques éléments importants qui vous permettront d'avoir une première idée du niveau de sécurité d'une image Docker. Également, certains éléments caractéristiques d'une image malveillante peuvent être découverts grâce à ces outils, mais il faut garder en tête le fait qu'un attaquant peut très bien dissimuler son action. L'utilisation d'images officielles reste donc la meilleure mesure.
En gardant constamment en tête les risques associés à l'utilisation d'images Docker externes au sein de votre système d'information ainsi que les bons réflexes, outils et pratiques d'administration, vous pourrez réduire ce risque et utiliser Docker de façon un peu plus sûr.
Cet article propose un premier aperçu sur l'importance d'analyser la sécurité des images Docker, mais il ne remplacera une formation complète sur cette technologie (et de la pratique). Restez donc curieux et au fait des nouvelles attaques et faiblesses qui peuvent apparaitre dans le futur autour de Docker.
Pour aller plus loin dans l'exploration de Docker, consultez nos autres articles sur ce sujet !
On pourrait ajouter dans les bonnes pratiques les notions de cgroup, nameapace, réseau Internal, Secret,.. Bref, tout comme une VM