8.8 KiB
\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.
{ width=90% }
Selon une étude1 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.
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 :
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 :
Utilisation
Une fois le plugin installé et la licence du service acceptée, nous pouvons commencer notre analyse :
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
</div>
<div lang="en-US">
$ 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
</div>
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` :
<div lang="en-US">
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)
</div>
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` :
<div lang="en-US">
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)
</div>
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 :
<div lang="en-US">
42sh$ docker run --rm -v /tmp/trivy-cache:/root/.cache/ aquasec/trivy
image IMAGE
</div>
### 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 :
<div lang="en-US">
```bash
--quiet --format template --template "@contrib/html.tpl"
En redirigeant la sortie standard vers un fichier, vous pourrez l'ouvrir dans votre navigateur favori.
{ width=80% }