diff --git a/tutorial/docker-internals/Makefile b/tutorial/docker-internals/Makefile index 83de36a..9bc06fc 100644 --- a/tutorial/docker-internals/Makefile +++ b/tutorial/docker-internals/Makefile @@ -1,4 +1,4 @@ -SOURCES = tutorial.md setup.md oci.md manifest.md runc.md linuxkit.md vxlan.md rendu.md +SOURCES = tutorial.md clair.md oci.md manifest.md runc.md linuxkit.md vxlan.md rendu.md PANDOCOPTS = --latex-engine=xelatex \ --standalone \ --normalize \ diff --git a/tutorial/docker-internals/clair.md b/tutorial/docker-internals/clair.md new file mode 100644 index 0000000..f62efd8 --- /dev/null +++ b/tutorial/docker-internals/clair.md @@ -0,0 +1,154 @@ +\newpage + +Une vision plus Clair de la sécurité ? +====================================== + +Nous avons vu, au travers de tous les précédents TP, que Docker nous apportait +un certain degré de sécurité d'emblée au lancement du conteneur. Cela peut sans +doute paraître quelque peu rassurant pour la personne chargée d'administrer la +machine hébergeant les 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 bibliothèques que l'on a installé ensuite. + +Convaincu ? Cela sonne encore comme des bonnes pratiques difficile à 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. + +![Rapport d'analyse statique des vulnérabilités d'un conteneur](paclair.png) + + +## Clair + +Le principal outil pour indexer et chercher des vulnérabilités est +[`Clair`](https://github.com/coreos/clair/), du projet CoreOS. À partir des +informations mises à disposition par les équipes de sécurités des principales +distributions, cela alimente en continu une base de données qui sera accéder au +moment de l'analyse. + +L'outil se présente sous la forme d'un serveur autonome dans la récupération +de ses données sources, auquel nous pourrons interagir au moyen d'une API : +pour lui envoyer des images et lui demander une analyse. Les clients de cette +API seront soit les registres directement, soit un programme dédié. + +![Scan de vulnérabilités sur le Docker Hub](hubvuln.png) + + +Commençons par lancer notre propre instance de `Clair`, à l'aide d'un +`docker-compose.yml` : + +
+```yml +version: '3' +services: + postgres: + container_name: clair_postgres + image: postgres:latest + restart: unless-stopped + environment: + - POSTGRES_PASSWORD + + clair: + container_name: clair_clair + image: quay.io/coreos/clair:v2.0.6 + restart: unless-stopped + depends_on: + - postgres + ports: + - "6060-6061:6060-6061" + links: + - postgres + volumes: + - /tmp:/tmp + - ./clair_config:/config + command: [-config, /config/config.yaml] +``` +
+ +Vous trouverez un exemple de configuration dans le [dépôt du +projet](https://raw.githubusercontent.com/coreos/clair/master/config.yaml.sample). N'oubliez +pas de changer le nom d'hôte et le mot de passe pour se connecter au conteneur +de base de données. + +Une fois lancé, la base nécessite d'être initialisée. L'opération peut prendre +plusieurs minutes. Vous pouvez suivre l'avancement de l'ajout : + +
+```shell + curl http://localhost:6060/v1/namespaces + curl http://localhost:6060/v1/namespaces/debian:9/vulnerabilities?limit=10 +``` +
+ + +## PAClair + +Afin de pouvoir réaliser à la demande et sans registre privé, l'analyse de +conteneur, nous allons utiliser le programme +[`paclair`](https://github.com/yebinama/paclair) : + +
+```shell + pip3 install paclair +``` +
+ +Il nécessite un fichier de configuration pour être utilisé, essayez : + +
+```yml + General: + clair_url: 'http://localhost:6060' + Plugins: + Docker: + class: paclair.plugins.docker_plugin.DockerPlugin +``` +
+ +Pour obtenir un rapport d'analyse, on commence par envoyer les couches de +l'image à `Clair` : + +
+```shell + paclair --conf conf.yml Docker nemunaire/fic-admin push +``` +
+ +Puis on lui demande la génération d'un rapport `html` : + +
+```shell + paclair --conf conf.yml Docker nemunaire/fic-admin analyse --output-format html --output-report file +``` +
+ +Si l'on souhaite uniquement avoir des statistiques dans la console : + +
+```shell + 42sh$ paclair --conf conf.yml Docker node:latest analyse --output-format stats + Unknown: 2 + Negligible: 1 + Medium: 5 + High: 4 +``` +
+ + +## Exercice {.unnumbered} + +Déterminez le nombre de vulnérabilités dans les principales images officielles +du [Docker Hub](https://hub.docker.com/explore), notamment `nginx`, `golang`, +`reddis`, ... diff --git a/tutorial/docker-internals/hubvuln.png b/tutorial/docker-internals/hubvuln.png new file mode 100644 index 0000000..454a509 Binary files /dev/null and b/tutorial/docker-internals/hubvuln.png differ diff --git a/tutorial/docker-internals/paclair.png b/tutorial/docker-internals/paclair.png new file mode 100644 index 0000000..5bae211 Binary files /dev/null and b/tutorial/docker-internals/paclair.png differ