\newpage Analyse de vulnérabilité ======================== Nous avons vu jusqu'à présent que Docker nous apportait un certain degré de sécurité d'emblée, au lancement de nos conteneurs. Cela peut sans doute paraître quelque peu rassurant pour une personne chargée d'administrer une machine hébergeant des conteneurs, car cela lui apporte des garanties quant à l'effort de cloisonnement mis en place. Mais doit-on pour autant s'arrêter là et considérer que nous avons réglé l'ensemble des problématiques de sécurité liées aux conteneurs ? Évidemment, non : une fois nos services lancés dans des conteneurs, ils ne sont pas moins exposés aux bugs et autres failles applicatives ; qu'elles soient dans notre code ou celui d'une bibliothèque, accessible par rebond, ... Il est donc primordial de ne pas laisser ses conteneurs à l'abandon une fois leur image créée et envoyée en production. Nos conteneurs doivent être regénérés sitôt que leur image de base est mise à jour (une mise à jour d'une image telle que Debian, Ubuntu ou Redhat n'apparaît que pour cela) ou bien lorsqu'un des programmes ou l'une des bibliothèques que l'on a installées est mise à jour. Convaincu ? Cela sonne encore comme des bonnes pratiques difficiles à mettre en œuvre, pouvant mettre en péril tout un système d'information. Pour s'en protéger, nous allons avoir besoin de réaliser à intervalles réguliers une analyse statique de nos conteneurs. ![Scan de vulnérabilités sur le Docker Hub](hubvuln.png){ width=90% } Selon une étude[^dockerhubvulnerability] réalisée sur les images du Docker Hub, elles présenteraient en moyenne 180 vulnérabilités, beaucoup ne sont pas mises à jour depuis trop longtemps et les vulnérabilités ont surtout tendance à se propager à cause de l'usage d'une image parente pas à jour. [^dockerhubvulnerability]: Une mesure efficace consiste à reconstruire régulièrement (et surtout automatiquement) les images que l'on publie sur un registre, sans oublier de mettre à jour l'image de base. D'ailleurs, avez-vous vérifié qu'une mise à jour de l'image `registry.nemunai.re/youp0m` n'était pas disponible depuis que vous avez commencé à l'utiliser ? Docker ne vérifie jamais si une mise à jour des images que vous avez précédemment téléchargées. Pensez donc régulièrement à appeler :
``` 42sh$ docker pull IMAGE ```
## Docker Scan Pour faire face à ces problèmes de sécurité qui prennent de l'ampleur, le Docker Hub, dans son modèle payant, permet d'analyser régulièrement ses images, pour avoir une idée sur la nécessité de les reconstruire. Un plugin existe pour réaliser des scans d'images présentes sur votre machine, à travers les données du Docker Hub. Cela nécessite d'avoir un compte Docker, si vous n'en avez pas, nous verrons dans la section suivante `trivy` qui permet de réaliser ses scans directement sur notre machine, sans passer par un intermédiaire. ::::: {.warning} Par cette méthode, vous êtes limité à 10 scans par mois avec un compte gratuit. ::::: ### Installation du plugin #### Windows et MacOS {-} Avec Docker Desktop, le plugin est déjà installé. Il faut que vous vous soyez préalablement connecté à votre compte Docker avec la commande `docker login`. #### Linux {-} Comme `docker scan` est un plugin, suivant la méthode d'installation que vous avez suivie, il n'a pas forcément été installé. Si vous obtenez un message d'erreur en lançant la commande, [voici comment récupérer le plugin et l'installer manuellement :](https://github.com/docker/scan-cli-plugin#on-linux)
``` mkdir -p ~/.docker/cli-plugins curl -L -s -S -o ~/.docker/cli-plugins/docker-scan \ https://github.com/docker/scan-cli-plugin/releases/\ latest/download/docker-scan_linux_amd64 chmod +x ~/.docker/cli-plugins/docker-scan ```
### Utilisation Une fois le plugin installé et la licence du service acceptée, nous pouvons commencer notre analyse :
``` 42sh$ docker scan nemunaire/youp0m Testing nemunaire/youp0m... Package manager: apk Project name: docker-image|nemunaire/youp0m Docker image: nemunaire/youp0m Platform: linux/amd64 Base image: alpine:3.16.2 ✓ Tested 15 dependencies for known vulnerabilities, no vulnerable paths found. According to our scan, you are currently using the most secure version of the selected base image ```
``` $ docker scan mysql Testing mysql... ✗ Low severity vulnerability found in util-linux/libuuid1 [...] ✗ High severity vulnerability found in gcc-8/libstdc++6 Description: Insufficient Entropy Info: https://snyk.io/vuln/SNYK-DEBIAN10-GCC8-469413 Introduced through: apt@1.8.2.3, mysql-community/mysql-client@[...] From: apt@1.8.2.3 > gcc-8/libstdc++6@8.3.0-6 From: mysql-community/mysql-client@8.0.26-1debian10 > gcc-8[...] From: mysql-community/mysql-server-core@8.0.26-1debian10 > gcc-8[...] and 7 more... Image layer: Introduced by your base image (mysql:8.0.26) Package manager: deb Project name: docker-image|mysql Docker image: mysql Platform: linux/amd64 Base image: mysql:8.0.30 Tested 119 dependencies for known vulnerabilities, found 24 vulnerabilities According to our scan, you are currently using the most secure version of the selected base image ```
Ce dernier exemple est sans appel : `mysql` est une image officielle, et sa dernière version à l'écriture de ses lignes contient pas moins de 24 vulnérabilités dont 9 *high* (pourtant corrigées dans des versions suivantes). ## Trivy Le principal outil pour chercher des vulnérabilités connues dans les images Docker est [`trivy`](https://www.aquasec.com/products/trivy/), édité par Aqua security. À partir des informations mises à disposition par les équipes de sécurité des principales distributions, `trivy` va générer un rapport, pour chacune de nos images, indiquant les vulnérabilités connues au sein de l'image. L'outil se présente sous la forme d'un binaire ou d'une image Docker, prenant un certain nombre d'arguments, notamment le nom de l'image à analyser. ### Utilisation Tentons à nouveau d'analyser l'image `mysql` :
``` 42sh$ docker run --rm aquasec/trivy image mysql INFO Need to update DB INFO Downloading DB... 100.00% 14.41 MiB p/s 2s INFO Detected OS: oracle INFO Detecting Oracle vulnerabilities... INFO Number of language-specific files: 0 mysql (oracle 8.6) ================== Total: 5 (UNKNOWN: 0, LOW: 0, MEDIUM: 4, HIGH: 1, CRITICAL: 0) ```
Les résultats sont un peu différents qu'avec `docker scan`, mais on constate que l'image `mysql` contient vraiment de nombreuses vulnérabilités. Même si elles ne sont heureusement pas forcément exploitables directement. Voyons maintenant s'il y a des différentes avec l'image `nemunaire/youp0m` :
``` 42sh$ docker run --rm aquasec/trivy image nemunaire/youp0m INFO Need to update DB INFO Downloading DB... 100.00% 15.98 MiB p/s 1s INFO Detected OS: alpine INFO Detecting Alpine vulnerabilities... INFO Number of language-specific files: 1 INFO Detecting gobinary vulnerabilities... nemunaire/youp0m (alpine 3.16.2) =================================== Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0) srv/youp0m (gobinary) ==================== Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0) ```
Nous pouvons remarque que Trivy, en plus de faire l'analyse statique des vulnérabilités de l'image, a aussi fait une analyse des dépendances du binaire `/srv/youp0m`. Trivy est en effet capable de rechercher des vulnérabilités par rapport aux dépendances connues de certains langages : Python, PHP, Node.js, .NET, Java, Go, ... ### Usage du cache Pour éviter de surcharger les serveurs de distributions de la base de données de vulnérabilités, nous devrions utiliser un cache pour faire nos analyses. Préférez lancer `trivy` avec les options suivantes :
``` 42sh$ docker run --rm -v /tmp/trivy-cache:/tmp/trivy/ aquasec/trivy \ --cache-dir /tmp/trivy IMAGE ```
### Format de génération du rapport Lorsque nous appelons `trivy` directement, il génère un rapport au format texte lisible directement dans notre terminal. Il peut être pourtant pratique de pouvoir l'exporter pour l'afficher dans un navigateur (par exemple pour le mettre à disposition des développeurs, lors d'une analyse automatique). Pour ce faire, on peut ajouter les options suivantes à la ligne de commande de notre conteneur :
```bash --quiet --format template --template "@contrib/html.tpl" ```
En redirigeant la sortie standard vers un fichier, vous pourrez l'ouvrir dans votre navigateur favori. ![Scan de vulnérabilités sur le registre Quay.io](quay-vulns.png){ width=80% } ## Clair