4 Regardez autour de vous : presque tout le monde package ses logiciels dans des conteneurs Docker, ou y réfléchit au minimum. Dire que les conteneurs ont tout changé dans notre façon d’aborder le développement logiciel est sans doute un euphémisme. Rien d’étonnant : l’époque où les développeurs devaient écrire une application distincte pour chaque plateforme est heureusement révolue, grâce à la nature légère, portable et facilement évolutive des conteneurs. LE PROBLÈME DES CONTENEURS Même si les conteneurs ont rendu beaucoup de choses plus simples et tout simplement meilleures, rien n’est jamais parfait, n’est-ce pas ? Pour cerner le problème, revenons aux bases. Une définition courante d’un conteneur en ligne est la suivante : « une instance d’un package exécutable qui inclut tout ce qui est nécessaire pour exécuter une application : code, fichiers de configuration, runtime, bibliothèques et packages, variables d’environnement, etc. ». Un conteneur est lancé à partir de ce qu’on appelle une image, composée d’une série de couches. Avec Docker, chaque couche représente une instruction d’un fichier texte appelé Dockerfile. Une image parente est la base sur laquelle votre image personnalisée est construite. La plupart des Dockerfiles partent d’une image parente. Lorsqu’on parle d’images de conteneurs, on se concentre souvent sur le logiciel particulier qui nous intéresse. Un article du blog AWS (en anglais) souligne pourtant qu’une image inclut tout un ensemble de logiciels qui jouent un rôle de support pour le composant principal. Même un développeur qui travaille régulièrement avec une image donnée peut n’avoir qu’une compréhension superficielle de tout ce qu’elle contient. Suivre toutes les bibliothèques et tous les packages inclus dans une image une fois celle-ci construite prend du temps. De plus, les développeurs récupèrent sans y penser des images depuis des dépôts publics où il est impossible de savoir qui a construit une image, avec quoi, et ce qu’elle contient exactement. Or, lorsque vous livrez votre application avec tout ce que contient le conteneur, vous êtes responsable de la sécurité. En cas de faille, c’est votre réputation qui risque d’être détruite. LES SCANNERS DE CONTENEURS Il est très difficile de savoir ce qui se passe sous le capot d’une image de conteneur. Les scanners d’images sont apparus pour résoudre ce problème, en offrant aux utilisateurs une visibilité plus ou moins poussée sur les images de conteneurs Docker. La plupart de ces outils exécutent la même série d’actions : Scan binaire de l’image Docker, décomposition en couches et établissement d’une nomenclature détaillée de son contenu. Capture (index) de l’OS et des packages. Comparaison de cette nomenclature avec une base de données de vulnérabilités connues et signalement des correspondances. Même si ces outils se ressemblent, ils ne sont pas identiques. Pour choisir, il faut évaluer leur efficacité : Jusqu’où le scan peut-il aller ? Autrement dit, la capacité du scanner à voir à l’intérieur des couches de l’image et de leur contenu (packages et fichiers). Le degré d’actualisation des listes de vulnérabilités. La présentation des résultats du scan, sous quelle forme et dans quel format. La capacité à réduire le bruit dans les données (doublons). 5 OUTILS À ENVISAGER Clair – outil du célèbre et apprécié CoreOS. C’est un moteur de scan pour l’analyse statique des vulnérabilités dans les conteneurs ou les clusters de conteneurs (comme Kubernetes). Statique signifie qu’il n’est pas nécessaire d’exécuter l’image du conteneur, et que vous pouvez détecter les menaces avant qu’elles n’entrent dans votre système. Clair maintient une base de données complète de vulnérabilités à partir de sources CVE configurées. Il expose des API permettant aux clients de lancer des scans d’images. Un scan indexe les éléments présents dans l’image, qui sont stockés dans la base de données. Les clients peuvent utiliser l’API Clair pour interroger la base de données sur les vulnérabilités d’une image donnée. Anchor – est un moteur puissant et bien maintenu de scan automatisé et d’application de politiques, intégrable aux pipelines CI/CD et aux images Docker. Les utilisateurs peuvent créer des listes blanches et des listes noires, et appliquer des règles. Il est disponible sous forme de navigateur SaaS gratuit en ligne pour scanner les dépôts publics, et sous forme de moteur open source pour les scans sur site. Le moteur sur site peut être branché à votre CI/CD via CLI ou REST pour faire échouer automatiquement les builds qui ne respectent pas les politiques définies. Voici un exemple de résultats de scan Anchor de l’image Docker Zenko cloudserver (la liste des dépendances Node.js) Au final, Anchore Engine fournit pour chaque image un résultat d’évaluation : conforme ou non aux politiques définies par l’utilisateur. Même s’il intègre des politiques de sécurité et de conformité, des fonctions et des points de décision prédéfinis, vous pouvez aussi écrire vos propres modules d’analyse et rapports. Dagda – est un outil d’analyse statique des vulnérabilités connues dans les images et conteneurs Docker. Dagda récupère des informations sur les logiciels installés dans vos images Docker, comme les packages de l’OS et les dépendances des langages de programmation, et vérifie pour chaque produit et chaque version l’absence de vulnérabilités en s’appuyant sur les informations préalablement stockées dans une instance MongoDB. Cette base inclut les vulnérabilités connues sous forme de CVE (Common Vulnerabilities and Exposures), de BID (Bugtraq IDs), de RHSA (Red Hat Security Advisories) et de RHBA (Red Hat Bug Advisories), ainsi que les exploits connus de la base Offensive Security. En outre, il utilise ClamAV pour détecter les virus et les malwares. À noter également : tous les rapports de scan de l’image ou du conteneur sont stockés dans MongoDB, où l’utilisateur peut les consulter. Docker Bench for Security – le Center of Internet Security a élaboré un guide pas à pas solide pour sécuriser Docker. L’équipe Docker a ensuite publié un outil (un script shell) qui s’exécute dans un petit conteneur et vérifie le respect de ces bonnes pratiques de déploiement des conteneurs Docker en production. OpenSCAP – il s’agit d’un écosystème complet d’outils qui aident à mesurer et à appliquer un socle de sécurité. Il comprend un outil dédié aux conteneurs, oscap-docker, qui effectue les scans CVE des conteneurs et les compare à des politiques prédéfinies. OSCAP Base est le scanner en ligne de commande de base, certifié NIST. OSCAP WorkBench est une interface graphique qui présente les résultats du scanner et se veut intuitive et conviviale. EN RÉSUMÉ Ces outils sont apparus parce que la popularité de Docker a grimpé très vite. Il y a deux ans à peine, il aurait été difficile de leur faire confiance, car ils commençaient tout juste à émerger. Aujourd’hui, ils sont plus aguerris face aux conteneurs Docker et aux défis nés de l’essor de cette technologie. La semaine prochaine, je passerai en revue d’autres outils et scanners davantage orientés conformité open source. C’est tout pour aujourd’hui. Prenez soin de vous et retrouvons-nous sur le forum.
