Update tuto2
This commit is contained in:
parent
5f097b4221
commit
2c5317f4f9
35 changed files with 3587 additions and 471 deletions
|
|
@ -1,53 +1,20 @@
|
|||
\newpage
|
||||
### Clair
|
||||
|
||||
Une vision plus Clair de la sécurité
|
||||
====================================
|
||||
|
||||
Nous avons vu, au travers de nos TPs jusqu'à présent, 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
|
||||
Un outil complet 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 :
|
||||
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` :
|
||||
`docker-compose.yml` :
|
||||
|
||||
<div lang="en-US">
|
||||
```yml
|
||||
|
|
@ -77,10 +44,10 @@ services:
|
|||
```
|
||||
</div>
|
||||
|
||||
Prenez quelques minutes pour comprendre ce `docker-compose.yml` : notez la
|
||||
présence de la variable d'environnement `POSTGRES_PASSWORD`, non définie : ce
|
||||
Prenez quelques minutes pour comprendre ce `docker-compose.yml` : notez la
|
||||
présence de la variable d'environnement `POSTGRES_PASSWORD`, non définie : ce
|
||||
sera la variable présente dans votre environnement, au moment du
|
||||
`docker-compose up` qui sera utilisée. N'oubliez pas de la définir :
|
||||
`docker-compose up` qui sera utilisée. N'oubliez pas de la définir :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -99,7 +66,7 @@ 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 via :
|
||||
plusieurs minutes. Vous pouvez suivre l'avancement de l'ajout via :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -109,11 +76,11 @@ curl http://localhost:6060/v1/namespaces/debian:9/vulnerabilities?limit=10
|
|||
</div>
|
||||
|
||||
|
||||
## PAClair
|
||||
### 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) :
|
||||
[`paclair`](https://github.com/yebinama/paclair) :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -121,7 +88,7 @@ pip3 install paclair
|
|||
```
|
||||
</div>
|
||||
|
||||
Il nécessite un fichier de configuration pour être utilisé, essayez :
|
||||
Il nécessite un fichier de configuration pour être utilisé, essayez :
|
||||
|
||||
<div lang="en-US">
|
||||
```yml
|
||||
|
|
@ -134,7 +101,7 @@ Plugins:
|
|||
</div>
|
||||
|
||||
Pour obtenir un rapport d'analyse, on commence par envoyer les couches de
|
||||
l'image à `Clair` :
|
||||
l'image à `Clair` :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -142,7 +109,7 @@ paclair --conf conf.yml Docker nemunaire/fic-admin push
|
|||
```
|
||||
</div>
|
||||
|
||||
Puis on lui demande la génération d'un rapport `html` :
|
||||
Puis on lui demande la génération d'un rapport `html` :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -150,7 +117,7 @@ paclair --conf conf.yml Docker nemunaire/fic-admin analyse --output-format html
|
|||
```
|
||||
</div>
|
||||
|
||||
Si l'on souhaite uniquement avoir des statistiques dans la console :
|
||||
Si l'on souhaite uniquement avoir des statistiques dans la console :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -161,10 +128,3 @@ Medium: 5
|
|||
High: 4
|
||||
```
|
||||
</div>
|
||||
|
||||
|
||||
## Exercice {-}
|
||||
|
||||
Déterminez le nombre de vulnérabilités dans les principales images officielles
|
||||
du [Docker Hub](https://hub.docker.com/explore), notamment `nginx`, `golang`,
|
||||
`redis`, ...
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue