9.2 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, il 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és ensuite 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 public, sans oublier de mettre à jour l'image de base.
D'ailleurs, avez-vous vérifié qu'une mise à jour de l'image nemunaire/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.
Attention {-}
Par cette méthode, vous êtes limité à 10 scans par mois.
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/fic-admin...
Package manager: apk Project name: docker-image|nemunaire/fic-admin Docker image: nemunaire/fic-admin Platform: linux/amd64 Base image: alpine:3.14.2
✓ Tested 16 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-community-client@8.0.26-1debian10, mysql-community/mysql-community-server-core@8.0.26-1debian10, mecab-ipadic@2.7.0-20070801+main-2.1, meta-common-packages@meta From: apt@1.8.2.3 > gcc-8/libstdc++6@8.3.0-6 From: mysql-community/mysql-community-client@8.0.26-1debian10 > gcc-8/libstdc++6@8.3.0-6 From: mysql-community/mysql-community-server-core@8.0.26-1debian10 > gcc-8/libstdc++6@8.3.0-6 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.26
Tested 135 dependencies for known vulnerabilities, found 79 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 79
vulnérabilités dont 11 *high*.
## 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 mysql 2021-09-22T10:27:46.509Z INFO Need to update DB 2021-09-22T10:27:46.509Z INFO Downloading DB... 100.00% 14.41 MiB p/s 2s 2021-09-22T10:27:56.556Z INFO Detected OS: debian 2021-09-22T10:27:56.556Z INFO Detecting Debian vulnerabilities... 2021-09-22T10:27:56.579Z INFO Number of language-specific files: 0
mysql (debian 10.10)
Total: 158 (UNKNOWN: 5, LOW: 19, MEDIUM: 64, HIGH: 61, CRITICAL: 9)
</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 exploitable directement.
Voyons maintenant s'il y a des différentes avec l'image `nemunaire/fic-admin` :
<div lang="en-US">
42sh$ docker run --rm aquasec/trivy nemunaire/fic-admin 2021-09-22T10:29:48.091Z INFO Need to update DB 2021-09-22T10:29:48.091Z INFO Downloading DB... 100.00% 15.98 MiB p/s 1s 2021-09-22T10:29:51.902Z INFO Detected OS: alpine 2021-09-22T10:29:51.902Z INFO Detecting Alpine vulnerabilities... 2021-09-22T10:29:51.903Z INFO Number of language-specific files: 1 2021-09-22T10:29:51.903Z INFO Detecting gobinary vulnerabilities...
nemunaire/fic-admin (alpine 3.14.2)
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
srv/admin (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/admin`.
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:/tmp/trivy/ aquasec/trivy
--cache-dir /tmp/trivy 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=90% }