Vous avez pensé à développer votre application en tenant compte de la sécurité ? Mais lors du build de votre image, avez-vous vérifié les CVE potentielles sur celle-ci ? Avez-vous vérifié l'image toute prête du Docker Hub que vous venez de récupérer ? Et pourtant ...

La présence de malware dans certaines images du Docker Hub n'est pas un mythe. De telles images ont déjà circulé, certaines circulent sûrement encore, et d'autres viendront. Il est important de vérifier de façon systématique la présence de vulnérabilités sur les images que vous utilisez. Et encore plus s' il s'agit d'une de vos créations !

Heureusement pour nous, il existe des outils afin de nous faciliter la tâche. Il existe toute une série de scanners dont voici une liste non exhaustive :

  • Anchore
  • Clair ( CoreOS )
  • Dagda
  • Trivy

Et bien d'autres ... Nous allons ici montrer le fonctionnement de certains de ces outils : Anchore et Trivy. Pourquoi avoir choisi ces deux solutions ?

Tout simplement car je trouve ces deux solutions complémentaires, car elles correspondent chacune à une utilisation que l'on peut avoir d'un scanner de vulnérabilités. Je vais vous expliquer tout ça !

Trivy

Trivy est un scanner de vulnérabilité pour les conteneurs qui se veut simple et complet. Ce n'est pas moi qui le dit, c'est la fiche du projet ... 😂 Mais je vous rassure, c'est le cas.

Il va détecter les vulnérabilités des packages OS (Alpine, RHEL, CentOS, etc.) et les dépendances des applications (Bundler, Composer, npm, yarn etc.).

Trivy peut s'installer de différentes façon :

  • Gestionnaire de paquets ( apt-get, yum, brew ... )
  • Sous forme d'image Docker !

Je vais justement utiliser cette dernière option. Tout d'abord créons un volume dans le quel sera stocké la base de vulnérabilités :

mkdir cache

Ensuite effectuons un scan, rien de plus simple :

 docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
    -v caches:/root/.cache/ aquasec/trivy python:3.4-alpine

Il n'est pas nécessaire d'utiliser la socket de l'hôte docker mais dans ce cas Trivy effectuera un nouveau téléchargement de l'image. Dans mon cas, je lie la socket afin d'utiliser la base d'image de mon hôte.

Le résultat va se présenter sous la forme :

python:3.4-alpine (alpine 3.9.2)
================================
Total: 13 (UNKNOWN: 0, LOW: 1, MEDIUM: 8, HIGH: 4, CRITICAL: 0)

+---------+------------------+----------+-------------------+---------------+--------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |             TITLE              |
+---------+------------------+----------+-------------------+---------------+--------------------------------+
| bzip2   | CVE-2019-12900   | HIGH     | 1.0.6-r6          | 1.0.6-r7      | bzip2: out-of-bounds write in  |
|         |                  |          |                   |               | function BZ2_decompress        |
+---------+------------------+----------+-------------------+---------------+

J'ai tronqué délibérément une partie du résultat.

Il existe quelques paramètres que nous pouvons passer à Trivy. Les plus importants selon moi :

--severity HIGH,CRITICAL

On ne remonte que les failles jugées critiques et hautes.

Et enfin :

--exit-code 1

Cette option est vraiment utile pour intégrer Trivy dans un runner gitlab afin de valider la sécurité de son image !

Le mode de fonctionnement que nous venons d'aborder est celui standalone. Il existe également un mode client/serveur.

J'utilise rarement Trivy dans ce cas de figure, car le serveur en réalité n'a qu'une seule mission : maintenir à jour la base de vulnérabilités. C'est pratique si vous souhaitez lancer énormément de scan via Trivy mais je conseillerai dans ce cas de choisir une autre solution.

Anchore Engine

Le moteur Anchore est un projet open source qui fournit un service centralisé d'inspection, d'analyse et de certification des images de conteneurs.

Il est fourni sous la forme d'une image Docker qui peut être exécutée de façon autonome ou s'intégrer au sein d'un orchestrateur comme Kubernetes, Docker Swarm, Rancher, etc.

Il se décompose en deux modules :

  • Le serveur,
  • Le client.

Il est nécessaire dans un premier temps de mettre en oeuvre le serveur. Comme pour Trivy, il existe des images Docker et surtout un fichier docker-compose qui se récupère de la façon suivante :

curl https://raw.githubusercontent.com/anchore/anchore-engine/master/docker-compose.yaml | sudo docker-compose -p anchore -f - up

Ce fichier va créer six conteneurs, dont celui de la base de vulnérabilités qui va se mettre à jour lors du premier démarrage. Cela peut forcément prendre un peu de temps.

Vous allez ensuite pouvoir lancer le client :

docker run --rm -e ANCHORE_CLI_URL=http://anchore_engine-api_1:8228/v1/ --network anchore_default -it anchore/engine-cli

Nous accédons à l'API du moteur via la variable d'environnement ANCHORE_CLI_URL, si vous n'avez pas fait de modification dans le fichier docker-compose, vous devriez avoir accès au shell de votre client :

[anchore@74d8bacaba4b anchore-cli]$ anchore-cli --version
anchore-cli, version 0.6.1

Pour scanner une image, il y a 2 étapes :

  • Ajouter l'image à numériser dans le moteur,
  • Attendre son analyse et demander le rapport de vulnérabilités.

Pour ajouter l'image au moteur d'analyse :

anchore-cli image add wordpress:5

Vous pouvez ensuite attendre la fin de l'analyse avec la commande suivante :

anchore-cli image wait wordpress:5

Une fois l'analyse terminée, le statut de l'image passera en analysée :

Status: analyzing
Waiting 5.0 seconds for next retry.
Image Digest: sha256:d47329a5dd40126efddd2b27e63f772d0ae9487f6564a54f6943f611a1a8b398
Parent Digest: sha256:c852a4bf0d2200a5e5808dfe13e26e797710309b60208a6a8d21455004a2e753
Analysis Status: analyzed
Image Type: docker
Analyzed At: 2020-03-21T21:01:27Z
Image ID: d44c65e8e9a3df3a430778dd06b3e5921414adae331253c9aee01274139dffd0
Dockerfile Mode: Guessed
Distro: debian
Distro Version: 10
Size: 557649920
Architecture: amd64
Layer Count: 21

Full Tag: docker.io/wordpress:5
Tag Detected At: 2020-03-21T20:59:01Z

Pour visualiser les vulnérabilités découvertes :

anchore-cli image vuln wordpress:5 all

L'option all va indiquer à Anchore de nous remonter les vulnérabilités des dépendances de l'application et de l'OS. Vous pouvez également utiliser l'option os par exemple pour ne remonter que les informations concernant le système d'exploitation.

Il existe de nombreuses possibilités offertes par Anchore que nous avons survolées lors de cet article. Mais ce premier aperçu vous permettra de réaliser quelques tests de vulnérabilités préventifs !

Vous n'avez maintenant plus aucune excuses pour ne pas scanner vos conteneurs ! Nous avons pu voir ensemble deux outils de scan qui sont complémentaires :

  • Trivy, le plus ... trivial ! Facile à mettre en oeuvre et à utiliser. Il peut s'intégrer facilement dans votre CI afin de valider la sécurité de vos images.
  • Anchore Engine plus complexe, mais qui offrira plus de possibilités également. Notamment pour des infrastructures plus importantes.

Il existe bien sûr d'autres options pour effectuer ce type de tests. De nombreux fournisseurs de registre d'image privée fournissent maintenant ce type de solution. Vous pouvez par exemple regarder du côté de Harbor si cela vous intéresse !

En tout cas  n'hésitez pas à m'apporter des remarques ou des commentaires sur Twitter, c'est toujours avec plaisir de voir vos retours ! 😘