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. + + + + +## 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é. + + + + +Commençons par lancer notre propre instance de `Clair`, à l'aide d'un +`docker-compose.yml` : + +