Les conteneurs nous ont bien facilité la vie: plus de conflits entre les gestionnaires de paquets OS / spécifiques à un langage, portabilité entre systèmes et platformes, isolation entre services et principalement: partage d’images grâce aux registres. Mais quel est le coût de cette facilité d’utilisation ?

Public visé : amoureux de k8s / helm et aficionados de cloud natif

Par Quentin Anglade, DevSecOps @ Objectif-Libre

Confort vs Sécurité: Images docker, charts helm et sandwichs

Question de confiance

La montée en puissance des conteneurs s’est accompagnée d’un glissement de la responsabilité de la maintenance et du support de la distribution des logiciels. Des mainteneurs de distributions linux et administrateurs systèmes qui installaient eux-mêmes les logiciels, nous sommes passés à Docker (pour les images officielles) et des inconnus sur le docker hub. Bien que n’importe qui soit libre d’utiliser et maintenir ses propres Dockerfiles, avouons qu’il est bien pratique de ne pas avoir à le faire. Les images sur le docker hub ont beaucoup de téléchargements et ce nombre en lui-même est déjà suffisant pour bon nombre d’utilisateurs. Une image avec 5 millions de pulls et mise à jour il y a 5 jours sera implicitement considérée comme fiable. Pour remuer le couteau dans la plaie, il n’y a pas de mécanisme répandu pour vérifier que l’image hébergée sur un registry corresponde au repository source associé (l’utilisation de builds automatiques et de cryptographie publique peut cependant aider). Ce problème n’est pas spécifique à docker (de nombreux dépôts de paquets et bibliothèques ont ce problème), il n’est pas plus technique qu’il n’est humain. Les utilisateurs vont simplement choisir la facilité à la sécurité, et la sécurité est souvent un peu (et parfois beaucoup) moins pratique.

Un sandwich complexe

Cependant, les conteneurs ne sont qu’une couche dans un sandwich complexe. Tout comme les conteneurs ont apporté leur lot de praticité au niveau applicatif, de nouveaux outils sont apparus par-dessus, prenant les innovations des outils de la couche précédente pour résoudre des problématiques d’au dessus. Vous pouvez répéter l’opération jusqu’à la fin du sandwich.

Avec les sandwichs, il suffit malheureusement qu’une seule tranche de fromage ne soit pas fraîche pour que le sandwich ait mauvais goût et puisse vous rendre malade, même si le reste du sandwich est parfaitement sain. Cela est au moins valable d’un point de vue sécurité.

Concernant cet article, la couche du dessus est Kubernetes, le système d’exploitation du cloud adopté massivement par la communauté. Mais il manque à cet OS un gestionnaire de paquets. Rajoutons-donc une couche de plus à notre sandwich : tout comme vous préféreriez utiliser apt install package plutôt que de compiler et installer manuellement un logiciel, vous voudrez probablement utiliser un chart helm pour vos besoins Kubernetes. Et vous avez raison ! Mais qui est le mainteneur ce chart, les images docker de ce chart et les logiciels contenus dans les images de ce chart ? Probablement des personnes ou entreprises différentes. Cette segmentation nous plonge dans un environnement où la chaine de confiance et la sécurité sont flous.

Helm-trivy: la confiance n’exclue pas le contrôle

Afin d’aider les developpeurs de charts helm et leurs utilisateurs à estimer rapidement la sécurité des images utilisées par un chart, nous avons développé un plugin helm: helm-trivy. Largement inspiré du plugin helm-snyk de Snyk.io, notre plugin utilise à la place trivy, dont l’utilisation est complètement gratuite. Snyk et trivy sont des outils qui peuvent scanner des images docker à la recherche de vulnérabilité connues. Ils peuvent être utilisés en CLI, dans une pipeline d’intégration continue, ou avec un plugin helm.

Le but de helm-trivy est de pouvoir rapidement scanner les images d’un chart, local ou public, sur votre machine locale ou dans une intégration continue. Pour être honnête, j’ai voulu fork helm-snyk, mais mes compétences et mon amour pour NodeJS m’ont poussé à réimplémenter un plugin en Golang. Vous pouvez l’essayer avec le système de plugins d’helm:

helm plugin install https://github.com/ObjectifLibre/helm-trivy

Vous pouvez ainsi scanner des charts public ou locaux:

# Mise à jour de repos
helm repo update

# Scan d'un chart public
helm trivy stable/mysql

# Scan d'un chart local
helm trivy path/to/your/chart

# Ne remonter que les sévérités hautes et critiques
helm trivy --trivyargs '--severity HIGH,CRITICAL' <chart>

# Scanner une version spécifique avec format json
helm trivy --json --version 1.2 <chart>

Vous pouvez contribuer à helm-trivy sur GitHub !