Conteneurs : la sécurité, affaire de minimalisme ?

Trend Micro (re)pose la question des techniques « minimalistes » utilisables pour réduire la surface d’attaque des conteneurs.

Avez-vous vraiment besoin de tout cela dans vos conteneurs ? Ainsi pourrait-on résumer la question – pas nouvelle – que pose Trend Micro. Le postulat : diminuer la taille des images, c’est certes minimiser leur consommation de ressources, mais aussi réduire la surface d’attaque.

Outils à l’appui (Syft pour l’analyse de composition logicielle, Grype pour la découverte de vulnérabilités), le groupe américain fait une première différence entre des images de base de Debian et d’Alpine Linux. Sans préciser lesquelles, mais en soulignant l’intérêt des distros Linux « légères ».

Reste que ces OS légers contiennent eux-mêmes des outils dont on pourrait souhaiter se débarrasser dans une logique de sécurité. Sur Alpine Linux, par exemple, le gestionnaire de paquets apk et l’exécutable BusyBox, qui réunit des outils UNIX.

Image scratch et build multistage, pour des conteneurs plus sûrs ?

Dans l’absolu, la réflexion peut aller jusqu’à très bas niveau. Trend Micro mentionne la commande base64, potentiellement exploitable pour décoder des charges malveillantes à l’exécution. « Beaucoup de fournisseurs cloud utilisent des conteneurs ou des micro-VM basés sur des images qui contiennent plus de paquets que requis », ajoute l’éditeur. Sans citer de noms, mais en livrant l’analyse d’une image de base de chez Google et de deux chez AWS. La première contient trois paquets, sans faille connue. Les deux autres, chacune plus d’une centaine, avec respectivement deux et quatre vulnérabilités.

La solution ? Associer image scratch et build multistage. La première est une image virtuelle vide : pas de shell, d’outils de débogage, de bibliothèques dynamiques…

Le second, arrivé en 2017 sur Docker, permet d’enchaîner les instructions FROM dans le Dockerfile, chacune lançant une étape pouvant reprendre – sélectivement – les éléments de la précédente. Ce qui évite des paliers intermédiaires (téléchargement de code, installation de dépendances…) et donc des couches supplémentaires. Une solution plus commode que d’optimiser la structure du Dockerfile ; par exemple en fusionnant les instructions RUN.

En associant ces deux dimensions, on se rapproche du principe du serverless, les applications étant segmentées en fonctions.

À lire en complément : comment sécuriser Kubernetes en 2022 ?