2020 done
This commit is contained in:
parent
fafac06b23
commit
a75f4b43b7
25 changed files with 113 additions and 2498 deletions
|
|
@ -3,7 +3,7 @@
|
|||
Une vision plus Clair de la sécurité
|
||||
====================================
|
||||
|
||||
Nous avons vu, au travers de tous les précédents TP, que Docker nous apportait
|
||||
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 à
|
||||
|
|
@ -62,7 +62,7 @@ services:
|
|||
|
||||
clair:
|
||||
container_name: clair_clair
|
||||
image: quay.io/coreos/clair:v2.0.6
|
||||
image: quay.io/coreos/clair:v2.0.9
|
||||
restart: unless-stopped
|
||||
depends_on:
|
||||
- postgres
|
||||
|
|
@ -77,13 +77,29 @@ services:
|
|||
```
|
||||
</div>
|
||||
|
||||
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
|
||||
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 :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
export POSTGRES_PASSWORD=$(openssl rand -base64 16)
|
||||
```
|
||||
</div>
|
||||
|
||||
Parmi les volumes partagés avec `clair`, il y a un dossier
|
||||
`./clair_config`. Notez le `./` au début, qui indique que le dossier sera
|
||||
recherché relativement par rapport à l'emplacement du `docker-compsose.yml`.
|
||||
|
||||
Dans ce dossier, vous devez placer un exemplaire du fichier de configuration
|
||||
dont un [exemple se trouve 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.
|
||||
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 :
|
||||
plusieurs minutes. Vous pouvez suivre l'avancement de l'ajout via :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
|
|
@ -151,4 +167,4 @@ High: 4
|
|||
|
||||
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`, ...
|
||||
`redis`, ...
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
\newpage
|
||||
|
||||
Registres
|
||||
=========
|
||||
|
||||
|
|
@ -17,11 +19,10 @@ L'authentification est facultative et est laissée à l'appréciation du
|
|||
fournisseur de service. Étant donné que nous allons utiliser le [Docker
|
||||
Hub](https://hub.docker.com/), le registre par défaut de `docker`, nous allons
|
||||
devoir nous plier à leur mécanisme d'authentification : chaque requête au
|
||||
registre doivent être effectuées avec un jeton, que l'on obtient en
|
||||
s'authentifiant auprès d'un service dédié. Ce service peut délivrer un jeton
|
||||
sans authentifier l'interlocuteur, en restant anonyme ; dans ce cas, on ne
|
||||
pourra accéder qu'aux images publiques. Ça tombe bien, c'est ce qui nous
|
||||
intéresse aujourd'hui !
|
||||
registre doit être effectuée avec un jeton, que l'on obtient en s'authentifiant
|
||||
auprès d'un service dédié. Ce service peut délivrer un jeton sans authentifier
|
||||
l'interlocuteur, en restant anonyme ; dans ce cas, on ne pourra accéder qu'aux
|
||||
images publiques. Ça tombe bien, c'est ce qui nous intéresse aujourd'hui !
|
||||
|
||||
Il n'en reste pas moins que le jeton est forgé pour un service donné (dans
|
||||
notre cas `registry.docker.io`) et avec un objectif bien cerné (pour nous, on
|
||||
|
|
@ -34,7 +35,7 @@ souhaite récupérer le contenu du dépôt[^quiddepot] `hello-world` :
|
|||
<div lang="en-US">
|
||||
```bash
|
||||
42sh$ curl "https://auth.docker.io/token?service=registry.docker.io&"\
|
||||
> "scope=repository:library/hello-world:pull" | jq .
|
||||
"scope=repository:library/hello-world:pull" | jq .
|
||||
```
|
||||
```json
|
||||
{
|
||||
|
|
@ -57,6 +58,12 @@ Avec `jq`, on peut l'extraire grâce à :
|
|||
```
|
||||
</div>
|
||||
|
||||
**Attention :** le token expire ! Pensez à le renouveler régulièrement.
|
||||
|
||||
En cas d'erreur inexplicable, vous pouvez ajouter un `-v` à la ligne de
|
||||
commande `curl`, afin d'afficher les en-têtes. Prêtez une attention toute
|
||||
particulière à `Www-Authenticate`.
|
||||
|
||||
|
||||
## Lecture de l'index d'images
|
||||
|
||||
|
|
@ -98,7 +105,9 @@ constater qu'il n'a bien qu'une seule couche, ouf !
|
|||
## Récupération de la configuration et de la première couche
|
||||
|
||||
Les deux éléments que l'on cherche à récupérer vont se trouver dans le
|
||||
répertoire `blobs`, il ne s'agit en effet plus de manifest. Si les manifests sont toujours stockés par le registre lui-même, les blobs peuvent être délégués à un autre service, par exemple dans le cloud, chez Amazon S3, un CDN, etc.
|
||||
répertoire `blobs`, il ne s'agit en effet plus de manifest. Si les manifests
|
||||
sont toujours stockés par le registre lui-même, les blobs peuvent être délégués
|
||||
à un autre service, par exemple dans le cloud, chez Amazon S3, un CDN, etc.
|
||||
|
||||
Pour récupérer la configuration de l'image :
|
||||
|
||||
|
|
@ -153,7 +162,7 @@ Réalisez un script pour automatiser l'ensemble de ces étapes :
|
|||
```bash
|
||||
42sh$ cd $(mktemp)
|
||||
|
||||
42sh$ ~/workspace/registry_play.sh library/hello-world
|
||||
42sh$ ~/workspace/registry_play.sh library/hello-world:latest
|
||||
|
||||
42sh$ find
|
||||
.
|
||||
|
|
@ -165,3 +174,6 @@ Hello from Docker!
|
|||
[...]
|
||||
```
|
||||
</div>
|
||||
|
||||
Pensez également à tester avec d'autres images, comme par exemple
|
||||
`nemunaire/youp0m`. Il vous faudra alors extraire plusieurs couches.
|
||||
|
|
|
|||
|
|
@ -4,11 +4,10 @@
|
|||
======
|
||||
|
||||
`runc` est le programme qui est responsable de la création effective du
|
||||
conteneur : c'est lui qui va mettre en place les *namespaces*, les
|
||||
*capabilities*, les points de montages ou volumes, ... Attention, son rôle
|
||||
reste limité à la mise en place de l'environnement conteneurisé, ce n'est pas
|
||||
lui qui télécharge l'image, ni fait l'assemblage des couches de système de
|
||||
fichiers, entre autres.
|
||||
conteneur : c'est lui qui va mettre en place toute la machinerie, les points de
|
||||
montages ou volumes, ... Attention, son rôle reste limité à la mise en place de
|
||||
l'environnement conteneurisé, ce n'est pas lui qui télécharge l'image, ni fait
|
||||
l'assemblage des couches de système de fichiers, entre autres.
|
||||
|
||||
Aujourd'hui, le lancement de conteneur est faite avec `runc`, mais il est
|
||||
parfaitement possible d'utiliser n'importe quel autre programme à sa place, à
|
||||
|
|
@ -23,7 +22,7 @@ essayer de lancer un shell `alpine` avec un volume dans notre home.
|
|||
|
||||
Vous devriez avoir le binaire `runc` ou `docker-runc`. Si ce n'est pas le cas,
|
||||
vous pouvez télécharger la dernière version :
|
||||
<https://github.com/opencontainers/runc/releases>. La 1.0.0-rc5 est Ok.
|
||||
<https://github.com/opencontainers/runc/releases>. La 1.0.0-rc9 est Ok.
|
||||
|
||||
|
||||
## Extraction du rootfs
|
||||
|
|
@ -56,6 +55,9 @@ runc spec
|
|||
Pour savoir à quoi correspondent tous ces éléments, vous pouvez consulter :
|
||||
<https://github.com/opencontainers/runtime-spec/blob/master/config.md>
|
||||
|
||||
Nous verrons dans les prochains TP, plus en détails tout ce qui porte sur les
|
||||
*namespaces*, rassurez-vous, il n'y a que très peu de champs à modifier
|
||||
aujourd'hui.
|
||||
|
||||
## Test brut
|
||||
|
||||
|
|
@ -127,11 +129,22 @@ ajouter un élément à cette liste, demandant de *bind* :
|
|||
|
||||
## Exercice {-}
|
||||
|
||||
Serez-vous capable de continuer l'édition de votre `config.json` afin d'obtenir
|
||||
les mêmes restrictions que votre projet de moulette ?
|
||||
À vous maintenant d'éditer votre `config.json`, pour lancer le service youp0m.
|
||||
|
||||
* CGroups : 1\ GB RAM, 100\ PIDs, ...
|
||||
* strict minimum de capabilities ;
|
||||
* filtres `seccomp` ;
|
||||
* carte réseau `veth` ;
|
||||
* ...
|
||||
Dans un premier temps, assurez-vous de pouvoir télécharger et d'assembler
|
||||
rapidement les couches du conteneur.
|
||||
|
||||
À partir du fichier `config.json` fourni, adaptez la ligne de commande à lancer
|
||||
et le dossier courant par défaut (`cwd`). Pensez également à faire un volume
|
||||
entre un dossier de votre home (ou temporaire, peu importe), afin de pouvoir
|
||||
stocker les photos (dossier `/srv/images`)[^chmod].
|
||||
|
||||
[^chmod]: faites attention aux droits du dossier que vous partagez. Le plus
|
||||
simple pour l'instant serait d'attribuer les permissions `0777` à la
|
||||
source, temporairement.
|
||||
|
||||
Pour ce TP, considérez que vous avez réussi si vous voyez s'afficher :
|
||||
|
||||
> `Ready, listening on :8080`
|
||||
|
||||
Il faudra attendre les TP suivants pour avoir du réseau dans notre conteneur.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue