Vous êtes ici : Formations en Ligne Gratuites » Catalogue » workbooks » DOF200 - Présentation de la Formation » DOF204 - Gestion de la Sécurité de Docker

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

--- elearning:workbooks:docker2:drf03 [2020/05/28 15:22] – admin
+++ elearning:workbooks:docker2:drf03 [2021/12/29 10:32] (Version actuelle) – admin
@@ Ligne 1: / Ligne 1: @@
 ~~PDF:LANDSCAPE~~
-Version : **2020.01**
+Version : **2022.01**
 Dernière mise-à-jour : ~~LASTMOD~~
@@ Ligne 10: / Ligne 11: @@
   * **DOF204 - Gestion de la Sécurité de Docker**
-    * LAB #8 - Création d'un Utilisateur de Confiance pour Contrôler le Daemon Docker
+    * Contenu du Module
-    * LAB #9 - Le Script docker-bench-security.sh
+    * LAB #1 - Travailler avec les CGroups
-    * LAB #10 - Sécurisation de la Configuration de l'Hôte Docker
+      * 1.1 - Présentation des Namespaces
-    * LAB #11 - Sécurisation de la Configuration du daemon Docker
+      * 1.2 - Présentation des CGroups
-      * Le Fichier /etc/docker/daemon.json
+      * 1.3 - Limitation de la Mémoire
-    * LAB #12 - Sécurisation des Images et les Fichiers de Construction
+      * 1.4 - Le Paquet cgroup-tools
-    * LAB #13 - Sécurisation du Container Runtime
+        * La commande cgcreate
-    * LAB #14 - Sécurisation des Images avec Docker Content Trust
+        * La Commande cgexec
-      * DOCKER_CONTENT_TRUST
+        * La Commande cgdelete
-      * DCT et la commande docker pull
+        * Le Fichier /etc/cgconfig.conf
-      * L'option disable-content-trust
+    * LAB #2 - Utilisation des Docker Secrets
-      * DCT et la commande docker push
+    * LAB #3 - Création d'un Utilisateur de Confiance pour Contrôler le Daemon Docker
-      * DCT et la commande docker build
+    * LAB #4 - Le Script docker-bench-security.sh
-      * Créer un deuxième Repositry
+    * LAB #5 - Sécurisation de la Configuration de l'Hôte Docker
-      * Supprimer une Signature
+      * 5.1 - [WARN] 1.2.1 - Ensure a separate partition for containers has been created
-    * LAB #15 - Sécurisation du Socket du Daemon Docker
+      * 5.2 - [WARN] 1.2.3 - Ensure auditing is configured for the Docker daemon
-      * Création du Certificat de l'Autorité de Certification
+    * LAB #6 - Sécurisation de la Configuration du daemon Docker
-      * Création du Certificat du Serveur Hôte du Daemon Docker
+      * 6.1 - [WARN] 2.1 - Ensure network traffic is restricted between containers on the default bridge
-      * Création du Certificat du Client
+      * 6.2 - [WARN] 2.8 - Enable user namespace support
-      * Démarrage du Daemon Docker avec une Invocation Directe
+      * 6.3 - [WARN] 2.11 - Ensure that authorization for Docker client commands is enabled
-      * Configuration du Client
+      * 6.4 - [WARN] 2.12 - Ensure centralized and remote logging is configured
+      * 6.5 - [WARN] 2.14 - Ensure Userland Proxy is Disabled
+      * 6.6 - [WARN] 2.17 - Ensure containers are restricted from acquiring new privileges
+      * 6.7 - Le Fichier /etc/docker/daemon.json
+    * LAB #7 - Sécurisation des Images et les Fichiers de Construction
+      * 7.1 - [WARN] 4.1 - Ensure a user for the container has been created
+      * 7.2 - [WARN] 4.5 - Ensure Content trust for Docker is Enabled
+      * 7.3 - [WARN] 4.6 - Ensure that HEALTHCHECK instructions have been added to container images
+    * LAB #8 - Sécurisation du Container Runtime
+      * 8.1 - [WARN] 5.1 - Ensure AppArmor Profile is Enabled
+      * 8.2 - [WARN] 5.2 - Ensure SELinux security options are set, if applicable
+      * 8.3 - [WARN] 5.10 - Ensure memory usage for container is limited
+      * 8.4 - [WARN] 5.11 - Ensure CPU priority is set appropriately on the container
+      * 8.5 - [WARN] 5.12 - Ensure the container's root filesystem is mounted as read only
+      * 8.6 - [WARN] 5.14 - Ensure 'on-failure' container restart policy is set to '5'
+      * 8.7 - [WARN] 5.25 - Ensure the container is restricted from acquiring additional privileges
+      * 8.8 - [WARN] 5.26 - Ensure container health is checked at runtime
+      * 8.9 - [WARN] 5.28 - Ensure PIDs cgroup limit is used
+    * LAB #9 - Sécurisation des Images avec Docker Content Trust
+      * 9.1 - DOCKER_CONTENT_TRUST
+      * 9.2 - DCT et la commande docker pull
+        * L'option disable-content-trust
+      * 9.3 - DCT et la commande docker push
+      * 9.4 - DCT et la commande docker build
+        * Créer un deuxième Repositry
+        * Supprimer une Signature
+    * LAB #10 - Sécurisation du Socket du Daemon Docker
+      * 10.1 - Création du Certificat de l'Autorité de Certification
+      * 10.2 - Création du Certificat du Serveur Hôte du Daemon Docker
+      * 10.3 - Création du Certificat du Client
+      * 10.4 - Démarrage du Daemon Docker avec une Invocation Directe
+      * 10.5 - Configuration du Client
+=====LAB #1 - Travailler avec les CGroups======
+====1.1 - Présentation des Namespaces====
+Les espaces de noms permettent de regrouper des processus dans un même espace et d'attribuer des droits sur des ressources par espace. Ceci permet l'exécution de plusieurs init, chacun dans un namespace, afin de recréer un environnement pour les processus qui doivent être isolés.
+====1.2 - Présentation des CGroups====
+Les Groupes de Contrôles (Control Groups) aussi appelés **CGroups**, sont une nouvelle façon de contrôler et de limiter des ressources. Les groupes de contrôle permettent l'allocation de ressources, même d'une manière dynamique pendant que le système fonctionne, telles le temps processeur, la mémoire système, la bande réseau, ou une combinaison de ces ressources parmi des groupes de tâches (processus) définis par l'utilisateur et exécutés sur un système.
+Les CGroups sont organisés de manière hiérarchique, comme des processus. Par contre, la comparaison entre les deux démontre que tandis que les processus se trouvent dans une arborescence unique descendant tous du processus init et héritant de l'environnement de leurs parents, les CGroups peuvent être multiples donnant lieu à des arborescences ou **hiérarchies** multiples qui héritent de certains attributs de leurs groupes de contrôle parents.
+Ces hiérarchies multiples et séparés sont necéssaires parce que chaque hiérarchie est attaché à un ou plusieurs sous-système(s) aussi appelés des **Contrôleurs de Ressources** ou simplement des **Contrôleurs**. Les contrôleurs disponibles sont :
+  * **blkio** - utilisé pour établir des limites sur l'accès des entrées/sorties à partir et depuis des périphériques blocs,
+  * **cpu** - utilisé pour fournir aux tâches des groupes de contrôle accès au CPU grâce au planificateur,
+  * **cpuacct** - utilisé pour produire des rapports automatiques sur les ressources CPU utilisées par les tâches dans un groupe de contrôle,
+  * **cpuset** - utilisé pour assigner des CPU individuels sur un système multicœur et des nœuds de mémoire à des tâches dans un groupe de contrôle,
+  * **devices** - utilisé pour autoriser ou pour refuser l'accès des tâches aux périphériques dans un groupe de contrôle,
+  * **freezer** - utilisé pour suspendre ou pour réactiver les tâches dans un groupe de contrôle,
+  * **memory** - utilisé pour établir les limites d'utilisation de la mémoire par les tâches d'un groupe de contrôle et pour génèrer des rapports automatiques sur les ressources mémoire utilisées par ces tâches,
+  * **net_cls** - utilisé pour repérer les paquets réseau avec un identifiant de classe (classid) afin de permettre au contrôleur de trafic Linux, **tc**, d'identifier les paquets provenant d'une tâche particulière d'un groupe de contrôle.
+  * **perf_event** - utilisé pour permettre le monitoring des CGroups avec l'outil perf,
+  * **hugetlb** - utilisé pour limiter des ressources sur des pages de mémoire virtuelle de grande taille.
+Les hiérarchies ont des points de montage dans le répertoire **/sys/fs/cgroup** :
+<code>
+trainee@debian9:~$ su -
+Mot de passe : fenestros
+root@debian9:~# ls -l /sys/fs/cgroup/
+total 0
+dr-xr-xr-x 2 root root  0 mai   26 08:52 blkio
+lrwxrwxrwx 1 root root 11 mai   26 08:52 cpu -> cpu,cpuacct
+lrwxrwxrwx 1 root root 11 mai   26 08:52 cpuacct -> cpu,cpuacct
+dr-xr-xr-x 2 root root  0 mai   26 08:52 cpu,cpuacct
+dr-xr-xr-x 2 root root  0 mai   26 08:52 cpuset
+dr-xr-xr-x 5 root root  0 mai   26 08:52 devices
+dr-xr-xr-x 2 root root  0 mai   26 08:52 freezer
+dr-xr-xr-x 2 root root  0 mai   26 08:52 memory
+lrwxrwxrwx 1 root root 16 mai   26 08:52 net_cls -> net_cls,net_prio
+dr-xr-xr-x 2 root root  0 mai   26 08:52 net_cls,net_prio
+lrwxrwxrwx 1 root root 16 mai   26 08:52 net_prio -> net_cls,net_prio
+dr-xr-xr-x 2 root root  0 mai   26 08:52 perf_event
+dr-xr-xr-x 5 root root  0 mai   26 08:52 pids
+dr-xr-xr-x 5 root root  0 mai   26 08:52 systemd
+</code>
+**Systemd** organise les processus dans chaque CGroup. Par exemple tous les processus démarrés par le serveur Apache se trouveront dans le même CGroup, y compris les scripts CGI. Ceci implique que la gestion des ressources en utilisant des hiérarchies est couplé avec l'arborescence des unités de Systemd.
+En haut de l'arborescence des unités de Systemd se trouve la tranche root - **-.slice**, dont dépend :
+  * le **system.slice** - l'emplacement des services système,
+  * le **user.slice** - l'emplacement des sessions des utilisateurs,
+  * le **machine.slice** - l'emplacement des machines virtuelles et conteneurs.
+En dessous des tranches peuvent se trouver :
+  * des **scopes** - des processus crées par **fork**,
+  * des **services** - des processus créés par une **Unité**.
+Les slices peuvent être visualisés avec la commande suivante :
+<code>
+root@debian9:~# systemctl list-units --type=slice
+UNIT               LOAD   ACTIVE SUB    DESCRIPTION
+-.slice            loaded active active Root Slice
+system-getty.slice loaded active active system-getty.slice
+system.slice       loaded active active System Slice
+user-1000.slice    loaded active active User Slice of trainee
+user-112.slice     loaded active active User Slice of lightdm
+user.slice         loaded active active User and Session Slice
+LOAD   = Reflects whether the unit definition was properly loaded.
+ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
+SUB    = The low-level unit activation state, values depend on unit type.
+loaded units listed. Pass --all to see loaded but inactive units, too.
+To show all installed unit files use 'systemctl list-unit-files'.
+</code>
+L'arborescence des unités de Systemd est la suivante :
+<code>
+root@debian9:~# systemd-cgls
+Control group /:
+-.slice
+├─user.slice
+│ ├─user-112.slice
+│ │ ├─user@112.service
+│ │ │ ├─dbus.service
+│ │ │ │ └─539 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
+│ │ │ ├─init.scope
+│ │ │ │ ├─527 /lib/systemd/systemd --user
+│ │ │ │ └─528 (sd-pam)
+│ │ │ └─gvfs-daemon.service
+│ │ │   └─547 /usr/lib/gvfs/gvfsd
+│ │ └─session-c1.scope
+│ │   ├─524 lightdm --session-child 18 21
+│ │   ├─532 /usr/sbin/lightdm-gtk-greeter
+│ │   ├─534 /usr/lib/at-spi2-core/at-spi-bus-launcher --launch-immediately
+│ │   ├─541 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
+│ │   └─543 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
+│ └─user-1000.slice
+│   ├─session-2.scope
+│   │ ├─668 sshd: trainee [priv]
+│   │ ├─679 sshd: trainee@pts/0
+│   │ ├─680 -bash
+│   │ ├─689 su -
+│   │ ├─690 -su
+│   │ ├─708 systemd-cgls
+│   │ └─709 systemd-cgls
+│   └─user@1000.service
+│     └─init.scope
+│       ├─670 /lib/systemd/systemd --user
+│       └─671 (sd-pam)
+├─init.scope
+│ └─1 /sbin/init
+└─system.slice
+  ├─lightdm.service
+  │ ├─410 /usr/sbin/lightdm
+  │ ├─425 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
+  │ └─588 lightdm --session-child 14 21
+  ├─anacron.service
+lines 1-39
+</code>
+En utilisant Systemd, plusieurs ressources peuvent être limitées :
+  * **CPUShares** - par défaut 1024,
+  * **MemoryLimit** - limite exprimée en Mo ou en Go. Pas de valeur par défaut,
+  * **BlockIOWeight** - valeur entre 10 et 1000. Pas de valeur par défaut,
+  * **StartupCPUShares** - comme CPUShares mais uniquement appliqué pendant le démarrage,
+  * **StartupBlockIOWeight** - comme BlockIOWeight mais uniquement appliqué pendant le démarrage,
+  * **CPUQuota** - utilisé pour limiter le temps CPU, même quand le système ne fait rien.
+<WRAP center round important>
+**Important** : Consultez le manuel systemd.resource-control(5) pour voir les paramètres CGroup qui peuvent être passés à systemctl.
+</WRAP>
+====1.3 - Limitation de la Mémoire====
+Pour travailler avec les CGroups dans Debian 9, il convient d'installer les outils nécessaires :
+<code>
+root@debian9:~# apt-get install libcgroup1 cgroup-tools
+</code>
+Commencez ensuite par créer le script **hello-world.sh** qui servira à générer un processus pour travailler avec les CGroups :
+<code>
+root@debian9:~# vi hello-world.sh
+root@debian9:~# cat hello-world.sh
+#!/bin/bash
+while [ 1 ]; do
+	echo "hello world"
+	sleep 60
+done
+</code>
+Rendez le script exécutable et testez-le :
+<code>
+root@debian9:~# chmod u+x hello-world.sh
+root@debian9:~# ./hello-world.sh
+hello world
+hello world
+^C
+</code>
+Créez maintenant un CGroup dans le sous-système **memory** appelé **helloworld** :
+<code>
+root@debian9:~# mkdir /sys/fs/cgroup/memory/helloworld
+</code>
+Par défaut, ce CGroup héritera de l'ensemble de la mémoire disponible. Pour éviter cela, créez maintenant une limite de **40000000** octets pour ce CGroup :
+<code>
+root@debian9:~# echo 40000000 > /sys/fs/cgroup/memory/helloworld/memory.limit_in_bytes
+root@debian9:~# cat /sys/fs/cgroup/memory/helloworld/memory.limit_in_bytes
+39997440
+</code>
+<WRAP center round important>
+**Important** - Notez que les 40 000 000 demandés sont devenus 39 997 440 ce qui correspond à un nombre entier de pages mémoire du noyau de 4Ko. ( 39 997 440 / 4096 = 9 765 ).
+</WRAP>
+Lancez maintenant le script **helloworld.sh** :
+<code>
+root@debian9:~# ./hello-world.sh &
+[1] 1012
+root@debian9:~# hello world
+root@debian9:~# ps aux | grep hello-world
+root      1012  0.0  0.1  11172  2868 pts/0    S    10:24   0:00 /bin/bash ./hello-world.sh
+root      1015  0.0  0.0  12784   968 pts/0    S+   10:25   0:00 grep hello-world
+</code>
+Notez l'héritage par défaut :
+<code>
+root@debian9:~# ps -ww -o cgroup 1012
+CGROUP
+:devices:/user.slice,3:pids:/user.slice/user-1000.slice/session-2.scope,1:name=systemd:/user.slice/user-1000.slice/session-2.scope
+</code>
+Insérer le PID de notre script dans le CGroup **helloworld** :
+<code>
+root@debian9:~# echo 1012 > /sys/fs/cgroup/memory/helloworld/cgroup.procs
+</code>
+Notez maintenant l'héritage de la limitation de la mémoire - **2:memory:/helloworld** :
+<code>
+root@debian9:~# ps -ww -o cgroup 1012
+CGROUP
+:devices:/user.slice,3:pids:/user.slice/user-1000.slice/session-2.scope,2:memory:/helloworld,1:name=systemd:/user.slice/user-1000.slice/session-2.scope
+</code>
+Constatez ensuite l'occupation mémoire réelle :
+<code>
+root@debian9:~# cat /sys/fs/cgroup/memory/helloworld/memory.usage_in_bytes
+
+</code>
+Tuez le script **hello-world.sh** :
+<code>
+root@debian9:~# kill 1012
+root@debian9:~# ps aux | grep hello-world
+root      1038  0.0  0.0  12784   936 pts/0    S+   10:33   0:00 grep hello-world
+[1]+  Complété              ./hello-world.sh
+</code>
+Créez un second CGroup beaucoup plus restrictif :
+<code>
+root@debian9:~# mkdir /sys/fs/cgroup/memory/helloworld1
+root@debian9:~# echo 6000 > /sys/fs/cgroup/memory/helloworld1/memory.limit_in_bytes
+root@debian9:~# cat /sys/fs/cgroup/memory/helloworld1/memory.limit_in_bytes
+
+</code>
+Relancez le script **hello-world.sh** et insérez-le dans le nouveau CGroup :
+<code>
+root@debian9:~# ./hello-world.sh &
+[1] 1042
+root@debian9:~# hello world
+root@debian9:~# echo 1042 > /sys/fs/cgroup/memory/helloworld1/cgroup.procs
+</code>
+Attendez la prochaine sortie de **hello world** sur le canal standard puis constatez que le script s'arrête :
+<code>
+root@debian9:~# hello world
+[1]+  Processus arrêté      ./hello-world.sh
+</code>
+Consultez en suite la fin du fichier **/var/log/messages** :
+<code>
+root@debian9:~# tail /var/log/messages
+Jul 28 10:39:26 debian9 kernel: [ 1501.775169]  [<ffffffffabe6253d>] ? __do_page_fault+0x4bd/0x4f0
+Jul 28 10:39:26 debian9 kernel: [ 1501.775171]  [<ffffffffabfc2950>] ? SyS_brk+0x160/0x180
+Jul 28 10:39:26 debian9 kernel: [ 1501.775175]  [<ffffffffac41a358>] ? page_fault+0x28/0x30
+Jul 28 10:39:26 debian9 kernel: [ 1501.775176] Task in /helloworld1 killed as a result of limit of /helloworld1
+Jul 28 10:39:26 debian9 kernel: [ 1501.775180] memory: usage 4kB, limit 4kB, failcnt 17
+Jul 28 10:39:26 debian9 kernel: [ 1501.775180] memory+swap: usage 0kB, limit 9007199254740988kB, failcnt 0
+Jul 28 10:39:26 debian9 kernel: [ 1501.775181] kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
+Jul 28 10:39:26 debian9 kernel: [ 1501.775181] Memory cgroup stats for /helloworld1: cache:0KB rss:4KB rss_huge:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB
+Jul 28 10:39:26 debian9 kernel: [ 1501.775188] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
+Jul 28 10:39:26 debian9 kernel: [ 1501.775219] [ 1042]     0  1042     2795      732      10       3        0             0 hello-world.sh
+</code>
+<WRAP center round important>
+**Important** - Notez la trace **Task in /helloworld1 killed as a result of limit of /helloworld1**.
+</WRAP>
+====1.4 - Le Paquet cgroup-tools====
+Le paquet **cgroup-tools** installe des commandes dites //de facilité// dont :
+===La commande cgcreate===
+Cette commande permet la création d'un CGroup :
+<code>
+root@debian9:~# cgcreate -g memory:helloworld2
+root@debian9:~# ls -l /sys/fs/cgroup/memory/helloworld2/
+total 0
+-rw-r--r-- 1 root root 0 juil. 28 11:09 cgroup.clone_children
+--w--w--w- 1 root root 0 juil. 28 11:09 cgroup.event_control
+-rw-r--r-- 1 root root 0 juil. 28 11:09 cgroup.procs
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.failcnt
+--w------- 1 root root 0 juil. 28 11:09 memory.force_empty
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.kmem.failcnt
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.kmem.limit_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.kmem.max_usage_in_bytes
+-r--r--r-- 1 root root 0 juil. 28 11:09 memory.kmem.slabinfo
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.kmem.tcp.failcnt
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.kmem.tcp.limit_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.kmem.tcp.max_usage_in_bytes
+-r--r--r-- 1 root root 0 juil. 28 11:09 memory.kmem.tcp.usage_in_bytes
+-r--r--r-- 1 root root 0 juil. 28 11:09 memory.kmem.usage_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.limit_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.max_usage_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.move_charge_at_immigrate
+-r--r--r-- 1 root root 0 juil. 28 11:09 memory.numa_stat
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.oom_control
+---------- 1 root root 0 juil. 28 11:09 memory.pressure_level
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.soft_limit_in_bytes
+-r--r--r-- 1 root root 0 juil. 28 11:09 memory.stat
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.swappiness
+-r--r--r-- 1 root root 0 juil. 28 11:09 memory.usage_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 11:09 memory.use_hierarchy
+-rw-r--r-- 1 root root 0 juil. 28 11:09 notify_on_release
+-rw-r--r-- 1 root root 0 juil. 28 11:09 tasks
+</code>
+Il n'existe cependant pas de commande pour affecter une limitation de la mémoire :
+<code>
+root@debian9:~# echo 40000000 > /sys/fs/cgroup/memory/helloworld2/memory.limit_in_bytes
+</code>
+===La Commande cgexec===
+Cette commande permet d'insérer la limitation dans le CGroup **et** de lancer le script en une seule ligne :
+<code>
+root@debian9:~# cgexec -g memory:helloworld2 ./hello-world.sh &
+[2] 1860
+root@debian9:~# hello world
+root@debian9:~#
+</code>
+=== La Commande cgdelete===
+Une fois le script terminé, cette commande permet de supprimer le cgroup :
+<code>
+root@debian9:~# ps aux | grep *.sh
+root      1073  0.0  0.1  11172  2868 pts/0    S    11:18   0:00 /bin/bash ./hello-world.sh
+root      1076  0.0  0.0    528     4 pts/0    R+   11:18   0:00 grep hello-world.sh
+root@debian9:~# kill 1073
+root@debian9:~# ps aux | grep *.sh
+root      1078  0.0  0.0  12784   920 pts/0    S+   11:18   0:00 grep hello-world.sh
+[1]+  Complété              cgexec -g memory:helloworld2 ./hello-world.sh
+root@debian9:~# cgdelete memory:helloworld2
+root@debian9:~# ls -l /sys/fs/cgroup/memory/helloworld2/
+ls: impossible d'accéder à '/sys/fs/cgroup/memory/helloworld2/': Aucun fichier ou dossier de ce type
+</code>
+===Le Fichier /etc/cgconfig.conf===
+Afin de les rendre persistants, il convient de créer les CGroups dans le fichier **/etc/cgconfig.conf** :
+<code>
+root@debian9:~# vi /etc/cgconfig.conf
+root@debian9:~# cat /etc/cgconfig.conf
+group helloworld2 {
+	cpu {
+		cpu.shares = 100;
+	}
+	memory {
+		memory.limit_in_bytes = 40000;
+	}
+}
+</code>
+<WRAP center round important>
+**Important** - Notez la création de **deux** limitations, une de 40 000 octets de mémoire et l'autre de **100** **cpu.shares**. Cette dernière est une valeur exprimée sur 1 024, où 1 024 représente 100% du temps CPU. La limite fixée est donc equivalente à 9,77% du temps CPU.
+</WRAP>
+Créez donc les deux CGroups concernés :
+<code>
+root@debian9:~# cgcreate -g memory:helloworld2
+root@debian9:~# ls -l /sys/fs/cgroup/memory/helloworld2/
+total 0
+-rw-r--r-- 1 root root 0 juil. 28 12:47 cgroup.clone_children
+--w--w--w- 1 root root 0 juil. 28 12:47 cgroup.event_control
+-rw-r--r-- 1 root root 0 juil. 28 12:47 cgroup.procs
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.failcnt
+--w------- 1 root root 0 juil. 28 12:47 memory.force_empty
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.kmem.failcnt
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.kmem.limit_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.kmem.max_usage_in_bytes
+-r--r--r-- 1 root root 0 juil. 28 12:47 memory.kmem.slabinfo
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.kmem.tcp.failcnt
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.kmem.tcp.limit_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.kmem.tcp.max_usage_in_bytes
+-r--r--r-- 1 root root 0 juil. 28 12:47 memory.kmem.tcp.usage_in_bytes
+-r--r--r-- 1 root root 0 juil. 28 12:47 memory.kmem.usage_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.limit_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.max_usage_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.move_charge_at_immigrate
+-r--r--r-- 1 root root 0 juil. 28 12:47 memory.numa_stat
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.oom_control
+---------- 1 root root 0 juil. 28 12:47 memory.pressure_level
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.soft_limit_in_bytes
+-r--r--r-- 1 root root 0 juil. 28 12:47 memory.stat
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.swappiness
+-r--r--r-- 1 root root 0 juil. 28 12:47 memory.usage_in_bytes
+-rw-r--r-- 1 root root 0 juil. 28 12:47 memory.use_hierarchy
+-rw-r--r-- 1 root root 0 juil. 28 12:47 notify_on_release
+-rw-r--r-- 1 root root 0 juil. 28 12:47 tasks
+</code>
+<code>
+root@debian9:~# cgcreate -g cpu:helloworld2
+root@debian9:~# ls -l /sys/fs/cgroup/cpu/helloworld2/
+total 0
+-rw-r--r-- 1 root root 0 juil. 28 12:48 cgroup.clone_children
+-rw-r--r-- 1 root root 0 juil. 28 12:48 cgroup.procs
+-r--r--r-- 1 root root 0 juil. 28 12:48 cpuacct.stat
+-rw-r--r-- 1 root root 0 juil. 28 12:48 cpuacct.usage
+-r--r--r-- 1 root root 0 juil. 28 12:48 cpuacct.usage_all
+-r--r--r-- 1 root root 0 juil. 28 12:48 cpuacct.usage_percpu
+-r--r--r-- 1 root root 0 juil. 28 12:48 cpuacct.usage_percpu_sys
+-r--r--r-- 1 root root 0 juil. 28 12:48 cpuacct.usage_percpu_user
+-r--r--r-- 1 root root 0 juil. 28 12:48 cpuacct.usage_sys
+-r--r--r-- 1 root root 0 juil. 28 12:48 cpuacct.usage_user
+-rw-r--r-- 1 root root 0 juil. 28 12:48 cpu.cfs_period_us
+-rw-r--r-- 1 root root 0 juil. 28 12:48 cpu.cfs_quota_us
+-rw-r--r-- 1 root root 0 juil. 28 12:48 cpu.shares
+-r--r--r-- 1 root root 0 juil. 28 12:48 cpu.stat
+-rw-r--r-- 1 root root 0 juil. 28 12:48 notify_on_release
+-rw-r--r-- 1 root root 0 juil. 28 12:48 tasks
+</code>
+Appliquez le contenu du fichier **/etc/cgconfig.conf** grâce à l'utilisation de la commande **cgconfigparser** :
+<code>
+root@debian9:~# cgconfigparser -l /etc/cgconfig.conf
+root@debian9:~# cat /sys/fs/cgroup/memory/helloworld2/memory.limit_in_bytes
+
+root@debian9:~# cat /sys/fs/cgroup/cpu/helloworld2/cpu.shares
+
+</code>
+=====LAB #2 - Utilisation des Docker Secrets=====
+Les secrets Docker sont une façon sécurisée de stocker des informations sensibles telles les noms d'utiisateurs, les mots de passe voire les fichiers. Ils ne sont compatibles qu'avec Docker en mode Swarm.
+Considérez l'exemple suivant d'un fichier Docker stack servant à créer un conteneur PostgreSQL :
+<file>
+version: '3.1'
+services:
+  db:
+    image: postgres
+    environment:
+      POSTGRES_USER: postgres
+      POSTGRES_PASSWORD: postgres
+      POSTGRES_DB: database
+  adminer:
+    image: adminer
+    ports:
+     - 8080:8080
+</file>
+On peut constater dans ce fichier la présence des informations sensibles en non-sécurisées :
+  * POSTGRES_USER
+  * POSTGRES_PASSWORD
+  * POSTGRES_DB
+Afin de sécuriser ces informations, commencez par créer le contexte **postgres** :
+<code>
+root@manager:~# mkdir postgres
+</code>
+Créez ensuite un Docker Secret appelé **pg_user** :
+<code>
+root@manager:~# cd postgres
+root@manager:~/postgres# echo "postgres" | docker secret create pg_user -
+lpk8eq80qvfiqw7z1686fmj5t
+</code>
+<WRAP center round important 60%>
+**Important** : Notez l'utilisation du caractère **-** à la fin de la ligne. Celui-ci indique à la commande **docker secret** de lire le contenu du secret pg_user à partir de l'entrée standard.
+</WRAP>
+Pour visualiser la liste des secrets, utilisez la commande docker secrets **ls** :
+<code>
+root@manager:~/postgres# docker secret ls
+ID                          NAME                DRIVER              CREATED              UPDATED
+lpk8eq80qvfiqw7z1686fmj5t   pg_user                                 About a minute ago   About a minute ago
+</code>
+<WRAP center round important 60%>
+**Important** : Notez que la colonne **DRIVER** est vide. Ceci indique que le gestion des secrets est accomplie par Docker lui-même au lieu d'être déléguée à un plugin tiers.
+</WRAP>
+Créez maintenant les secrets **pg_password** et **pg_database** :
+<code>
+root@manager:~/postgres# echo "postgres" | docker secret create pg_password -
+h9tsfbfwz6o0sd35roklwpopi
+root@manager:~/postgres# echo "database" | docker secret create pg_database -
+lx4zydpfocwgpdto0yy1jod9
+</code>
+<WRAP center round important 60%>
+**Important** : Notez qu'un secret Docker est immuable.
+</WRAP>
+Vérifiez la prise en compte de vos commandes :
+<code>
+root@manager:~/postgres# docker secret ls
+ID                          NAME                DRIVER              CREATED             UPDATED
+lx4zydpfocwgpdto0yy1jod9   pg_database                             2 minutes ago       2 minutes ago
+h9tsfbfwz6o0sd35roklwpopi   pg_password                             3 minutes ago       3 minutes ago
+lpk8eq80qvfiqw7z1686fmj5t   pg_user                                 5 minutes ago       5 minutes ago
+</code>
+Pour obtenir de l'information concernant un secret, il convient d'utiliser la commande docker secret **inspect** :
+<code>
+root@manager:~/postgres# docker secret inspect pg_database
+[
+    {
+        "ID": "5lx4zydpfocwgpdto0yy1jod9",
+        "Version": {
+            "Index": 23
+        },
+        "CreatedAt": "2021-04-15T03:49:36.344367554Z",
+        "UpdatedAt": "2021-04-15T03:49:36.344367554Z",
+        "Spec": {
+            "Name": "pg_database",
+            "Labels": {}
+        }
+    }
+]
+</code>
+<WRAP center round important 60%>
+**Important** : On peut constater dans la sortie de cette commande la valeur **CreatedAt** qui correspond à la date de création du secret ainsi que **UpdatedAt** qui correspond à la date de modification du secret.
+</WRAP>
+L'option **--pretty** de la commande fait apparaître ces informations plus clairement :
+<code>
+root@manager:~/postgres# docker secret inspect --pretty pg_database
+ID:              5lx4zydpfocwgpdto0yy1jod9
+Name:              pg_database
+Driver:
+Created at:        2021-04-15 03:49:36.344367554 +0000 utc
+Updated at:        2021-04-15 03:49:36.344367554 +0000 utc
+</code>
+Créez maintenant le fichier compose **postgres-secrets.yaml** :
+<code>
+root@manager:~/postgres# vi postgres-secrets.yaml
+root@manager:~/postgres# cat postgres-secrets.yaml
+version: '3.1'
+services:
+    db:
+        image: postgres
+        restart: always
+        environment:
+            POSTGRES_USER_FILE: /run/secrets/pg_user
+            POSTGRES_PASSWORD_FILE: /run/secrets/pg_password
+            POSTGRES_DB_FILE: /run/secrets/pg_database
+        secrets:
+           - pg_password
+           - pg_user
+           - pg_database
+    adminer:
+        image: adminer
+        ports:
+         - 8080:8080
+secrets:
+  pg_user:
+    external: true
+  pg_password:
+    external: true
+  pg_database:
+    external: true
+</code>
+Notez que dans ce fichier les trois variables **POSTGRES_USER**, **POSTGRES_PASSWORD** et **POSTGRES_DB** ont un suffixe **_FILE** car elles référencent des **fichiers** contenant des informations plutôt que des informations elles-mêmes. Ces fichiers se trouvent dans le répertoire **/run/secrets** du **conteneur**.
+Deuxièmement la section suivantes spécifie les noms des secrets à utiliser avec le service :
+<file>
+        secrets:
+           - pg_password
+           - pg_user
+           - pg_database
+</file>
+La dernière section spécifie que les secrets sont **externes** :
+<file>
+secrets:
+  pg_user:
+    external: true
+  pg_password:
+    external: true
+  pg_database:
+    external: true
+</file>
+<WRAP center round important 60%>
+**Important** : Le terme **externe** indique que les secrets ne seront pas stockés dans l'image construite mais **uniquement** dans le conteneur créé.
+</WRAP>
+Déployez maintenant le service en utilisant la commande **docker stack** :
+<code>
+root@manager:~/postgres# docker stack deploy -c postgres-secrets.yaml postgres
+Ignoring unsupported options: restart
+Creating network postgres_default
+Creating service postgres_db
+Creating service postgres_adminer
+</code>
+<WRAP center round important 60%>
+**Important** : Notez a présence de l'erreur **Ignoring unsupported options: restart**. Celle-ci est due au fait que la directive **restart** est compatible avec la commande **docker-compose** mais pas avec la commande **docker stack**. La directive qui aurait du être utilisée dans le fichier est **restart_policy:**.
+</WRAP>
+Connectez-vous maintenant à Apache Guacamole et ouvrez un navigateur web dans la machine virtuelle. Naviguez ensuite à l'adresse du Manager sur le port **8080** et renseignez les valeurs des secrets :
+{{ :elearning:workbooks:docker2:2021-04-15.png?direct&600 |}}
+Validez le formulaire et vérifiez que les secrets ont été pris en compte :
+{{ :elearning:workbooks:docker2:2021-04-15_1_.png?direct&600 |}}
+Dernièrement, supprimez le service :
+<code>
+root@manager:~/postgres# docker stack ls
+NAME                SERVICES            ORCHESTRATOR
+postgres            2                   Swarm
+root@manager:~/postgres# docker stack rm postgres
+Removing service postgres_adminer
+Removing service postgres_db
+Removing network postgres_default
+</code>
-=====LAB #8 - Création d'un Utilisateur de Confiance pour Contrôler le Daemon Docker=====
+=====LAB #3 - Création d'un Utilisateur de Confiance pour Contrôler le Daemon Docker=====
 Au contraire des solutions classiques de gestion de machines virtuelles où l'accès est souvent conditionné à l'attribution de rôles, Docker ne possède pas ce type de mécanisme. De ce fait toute personne ayant accès à l'hôte soit par **sudo** soit en étant membre du groupe **docker** peut accéder à tous les conteneurs voire les arrêter, supprimer et en créer d'autres.
@@ Ligne 50: / Ligne 746: @@
 trainee@manager:~$ docker rm alpine1
 alpine1
-trainee@manager:~$ docker run -d --name alpine1 alpine
+trainee@manager:~$ docker run -d --name alpine1 alpine sleep 99999
 a214e2df0499c97e8da25a6c9ea751ac75344c9bcd7d238f8cb8d5c777510ab9
 trainee@manager:~$ docker ps -a
@@ Ligne 57: / Ligne 753: @@
 </code>
-=====LAB #9 - Le Script docker-bench-security.sh=====
+=====LAB #4 - Le Script docker-bench-security.sh=====
 Le **Center for Internet Security (CIS)** est une organisation indépendante à but non-lucratif qui publie des best practices dans de nombreux domaines de l'informatique. Le guide pour Docker peut être téléchargé à partir de l'adresse [[https://www.cisecurity.org/benchmark/docker/]].
@@ Ligne 125: / Ligne 821: @@
   * **[NOTE]** : Vous informe d'un **best practice**.
-=====LAB #10 - Sécurisation de la Configuration de l'Hôte Docker=====
+=====LAB #5 - Sécurisation de la Configuration de l'Hôte Docker=====
 Lors de l'exécution du script, vous devez obtenir un résultat similaire à ceci en ce qui concerne la Sécurité de la Configuration de l'hôte Docker :
@@ Ligne 161: / Ligne 857: @@
 Les problèmes de sécurité qu'il convient à résoudre sont indiqués par les annotations **[WARN]**.
-====[WARN] 1.2.1 - Ensure a separate partition for containers has been created====
+====5.1 - [WARN] 1.2.1 - Ensure a separate partition for containers has been created====
 Par défaut, tous les fichiers de Docker sont stockés dans le répertoire **/var/lib/docker**, y compris toutes les images, tous les conteneurs et tous les volumes. Sur un système hôte n'ayant qu'une seule partition il y a un risque, tous comme le risque lié au répertoire **/var/log/**, que le disque devient saturé.
-====[WARN] 1.2.3  - Ensure auditing is configured for the Docker daemon====
+====5.2 - [WARN] 1.2.3  - Ensure auditing is configured for the Docker daemon====
 <file>
@@ Ligne 265: / Ligne 961: @@
 </code>
-=====LAB #11 - Sécurisation de la Configuration du daemon Docker=====
+=====LAB #6 - Sécurisation de la Configuration du daemon Docker=====
 Exécutez de nouveau le script **docker-bench-security.sh**. Vous devez obtenir un résultat similaire à ceci en ce qui concerne la sécurité de la configuration du daemon Docker :
@@ Ligne 296: / Ligne 992: @@
 Les problèmes de sécurité qu'il convient à résoudre sont indiqués par les annotations **[WARN]**.
-====[WARN] 2.1  - Ensure network traffic is restricted between containers on the default bridge====
+====6.1 - [WARN] 2.1  - Ensure network traffic is restricted between containers on the default bridge====
 Par défaut Docker permet un trafic réseau sans restrictions entre des conteneurs sur le même hôte. Il est cependant possible de modifier la configuration par défaut. Pour empêcher ceci, il faut fixer la valeur de **icc** à **false**. De cette façon, docker crée des conteneurs qui peuvent communiquer entre eux **uniquement** s'il existe un lien.
@@ Ligne 302: / Ligne 998: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/userguide/networking/|page]]**.
-====[WARN] 2.8  - Enable user namespace support====
+====6.2 - [WARN] 2.8  - Enable user namespace support====
 Cet avertissement nous indique que l'utilisation des **user namespaces** n'est pas activée. Le support des **user namespaces** du noyau Linux permet d'attribuer une plage d'UIDs et de GIDs unique à un processus et donc à un conteneur, en dehors de la plage traditionnelle utilisée par l'hôte Docker. L'avantage ici est que les processus ayant l'UID de root dans le conteneur seront mappés à un UID sans privilèges dans l'hôte Docker. Pour utiliser user namespace, il faut fixer la valeur de **userns-remap** à **default**. Dans ce cas précis Docker crée un utilisateur dénommé **dockremap**. Notez qu'il est aussi possible de fixer vos propres valeurs avec **"userns-remap": "user:group"**.
@@ Ligne 308: / Ligne 1004: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/security/userns-remap/|page]]**.
-====[WARN] 2.11  - Ensure that authorization for Docker client commands is enabled====
+====6.3 - [WARN] 2.11  - Ensure that authorization for Docker client commands is enabled====
 Par défaut, Docker permet un accès sans restrictions aux daemon Docker. Il est possible de restreindre l'accès à des utilisateurs authentifiés en utilisant un plug-in. Cette ligne est sans importance parce que l'accès au socket local Docker est limité aux membres du groupe **docker** (voir DOF202 - La Sécurité de la Configuration de l'Hôte Docker)
@@ Ligne 314: / Ligne 1010: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/extend/plugins_authorization/|page]]**.
-====[WARN] 2.12  - Ensure centralized and remote logging is configured====
+====6.4 - [WARN] 2.12  - Ensure centralized and remote logging is configured====
 Cet avertissement indique que la configuration de rsyslog ne permet pas l'envoie des traces vers un serveur de journalisation distant. Elle indique aussi que la valeur de **log-driver** n'a pas été spécifiée. Pour activer cette configuration, il faut fixer la valeur de **log-driver** à **syslog** puis configurer **syslog** ainsi que la valeur de **log-opts** correctement.
@@ Ligne 320: / Ligne 1016: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/admin/logging/overview/|page]]**.
-====[WARN] 2.14  - Ensure Userland Proxy is Disabled====
+====6.5 - [WARN] 2.14  - Ensure Userland Proxy is Disabled====
 Il existe deux méthodes pour qu'un conteneur puisse router vers l'extérieur :
@@ Ligne 331: / Ligne 1027: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/userguide/networking/default_network/binding/|page]]**.
-====[WARN] 2.17  - Ensure containers are restricted from acquiring new privileges====
+====6.6 - [WARN] 2.17  - Ensure containers are restricted from acquiring new privileges====
 Par défaut un conteneur peut obtenir une escalade de privilèges en utilisant les binaires setuid ou setgid. Pour interdire ceci il faut fixer la valeur de **no-new-privileges** à **true**.
@@ Ligne 337: / Ligne 1033: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/userguide/networking/default_network/binding/|page]]**.
-====Le Fichier /etc/docker/daemon.json ====
+====6.7 - Le Fichier /etc/docker/daemon.json ====
 Créez le fichier **/etc/docker/daemon.json** :
@@ Ligne 390: / Ligne 1086: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file/|page]]**.
-=====LAB #12 - Sécurisation des Images et les Fichiers de Construction=====
+=====LAB #7 - Sécurisation des Images et les Fichiers de Construction=====
 Créez le conteneur mysql :
@@ Ligne 442: / Ligne 1138: @@
 </code>
-====[WARN] 4.1  - Ensure a user for the container has been created====
+====7.1 - [WARN] 4.1  - Ensure a user for the container has been created====
-Les processus dans le conteneur **root-nginx** tourne sous l'UID de root. Ceci est l'action par défaut de Docker.
+Les processus dans le conteneur **mysql** tourne sous l'UID de root. Ceci est l'action par défaut de Docker.
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/security/security/|page]]**.
-====[WARN] 4.5  - Ensure Content trust for Docker is Enabled====
+====7.2 - [WARN] 4.5  - Ensure Content trust for Docker is Enabled====
 Cette ligne indique que le support de Content trust n'a pas été activé. Content trust permet de s'assurer de la provenance des images utilisées car celles-ci sont signées.
@@ Ligne 496: / Ligne 1192: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/security/trust/content_trust/|page]]**.
-====[WARN] 4.6  - Ensure that HEALTHCHECK instructions have been added to container images====
+====7.3 - [WARN] 4.6  - Ensure that HEALTHCHECK instructions have been added to container images====
 Quand une image est construite il est possible d'y mettre un **HEALTHCHECK** dont le statut peut être vérifié par Docker afin de relancer le conteneur si nécessaire.
@@ Ligne 510: / Ligne 1206: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/reference/builder/#healthcheck|page]]**.
-=====LAB #13 - Sécurisation du Container Runtime=====
+=====LAB #8 - Sécurisation du Container Runtime=====
 Exécutez de nouveau le script **docker-bench-security.sh**, vous devez obtenir un résultat similaire à ceci en ce qui concerne la sécurité du Container Runtime :
@@ Ligne 565: / Ligne 1261: @@
 Les problèmes de sécurité qu'il convient à résoudre sont indiqués par les annotations **[WARN]**.
-====[WARN] 5.1  - Ensure AppArmor Profile is Enabled====
+====8.1 - [WARN] 5.1  - Ensure AppArmor Profile is Enabled====
 Cet avertissement est présent parce que le conteneur n'utilise pas AppArmor.
@@ Ligne 571: / Ligne 1267: @@
 Pour plus d'informations, consultez cette **[[https://cloud.google.com/container-optimized-os/docs/how-to/secure-apparmor|page]]**.
-====[WARN] 5.2  - Ensure SELinux security options are set, if applicable====
+====8.2 - [WARN] 5.2  - Ensure SELinux security options are set, if applicable====
 Cet avertissement est présent parce que le conteneur n'utilise pas SELinux.
@@ Ligne 577: / Ligne 1273: @@
 Pour plus d'informations, consultez cette **[[https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/container_security_guide/docker_selinux_security_policy|page]]**.
-====[WARN] 5.10  - Ensure memory usage for container is limited====
+====8.3 - [WARN] 5.10  - Ensure memory usage for container is limited====
 Cet avertissement est du au fait que les conteneurs ont automatiquement accès à la totalité de la RAM de l'hôte Docker :
@@ Ligne 610: / Ligne 1306: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/config/containers/resource_constraints/|page]]**.
-====[WARN] 5.11  - Ensure CPU priority is set appropriately on the container====
+====8.4 - [WARN] 5.11  - Ensure CPU priority is set appropriately on the container====
 Cet avertissement est du au fait que les conteneurs ont automatiquement accès à tous les CPU de l'hôte Docker. Pour limiter cet accès, plusieurs options sont possibles dont le plus couramment utilisée est **--cpu-shares**.
@@ Ligne 618: / Ligne 1314: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/config/containers/resource_constraints/|page]]**.
-====[WARN] 5.12  - Ensure the container's root filesystem is mounted as read only====
+====8.5 - [WARN] 5.12  - Ensure the container's root filesystem is mounted as read only====
 Afin de minimiser le risque de compromettre un conteneur par la présence de code malicieux, il est conseillé de démarrer les conteneurs en lecture seule, sauf pour les volumes qui nécessitent un accès en écriture/lecture.
@@ Ligne 687: / Ligne 1383: @@
 </WRAP>
-====[WARN] 5.14  - Ensure 'on-failure' container restart policy is set to '5'====
+====8.6 - [WARN] 5.14  - Ensure 'on-failure' container restart policy is set to '5'====
 Cet avertissement concerne la politique de re-démarrage du conteneur. La politique **on-failure[:max-retries]** implique que le conteneur est re-démarré en cas d'arrêt du à une erreur qui se manifeste en tant que code de retour autre que zéro. La valeur de **max-retries** est le nombre de fois que Docker va essayer de re-démarrer le conteneur. Cette politique peut être mise en place au démarrage du conteneur, par exemple :
@@ Ligne 695: / Ligne 1391: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/config/containers/start-containers-automatically/|page]]**.
-====[WARN] 5.25  - Ensure the container is restricted from acquiring additional privileges====
+====8.7 - [WARN] 5.25  - Ensure the container is restricted from acquiring additional privileges====
 Pour complémenter la configuration précédemment mise en place, il convient de lancer le conteneur en utilisant l'option **--security-opt** :
@@ Ligne 703: / Ligne 1399: @@
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/reference/run/|page]]**.
-====[WARN] 5.26  - Ensure container health is checked at runtime====
+====8.8 - [WARN] 5.26  - Ensure container health is checked at runtime====
 Voir l'avertissement 4.6.
-====[WARN] 5.28  - Ensure PIDs cgroup limit is used====
+====8.9 - [WARN] 5.28  - Ensure PIDs cgroup limit is used====
 Sans l'utilisation de l'option **--pids-limit** un conteneur pourrait être victime d'une attaque de type **[[https://fr.wikipedia.org/wiki/Fork_bomb|Fork Bomb]]**, un type spécifique de dénie de service. Ce type d'attaque peut faire crasher l'hôte Docker et le seul remède est de re-démarrer l'hôte. Voici un exemple d'un Fork Bomb :
@@ Ligne 809: / Ligne 1505: @@
 </code>
-=====LAB #14 - Sécurisation des Images avec Docker Content Trust=====
+=====LAB #9 - Sécurisation des Images avec Docker Content Trust=====
 **Docker Content Trust (DCT)** a été introduit avec Docker Engine 1.8 et Docker CS Engine 1.9.0. DCT permet la vérification de l'authenticité, de l'intégrité et la date de publication d'une image Docker dans un registry. Par défaut, DCT est **désactivé**.
@@ Ligne 819: / Ligne 1515: @@
 Pour plus d'information concernant DCT, consultez cette **[[https://docs.docker.com/engine/security/trust/content_trust/|page]]**.
-====DOCKER_CONTENT_TRUST====
+====9.1 - DOCKER_CONTENT_TRUST====
 Pour utiliser **Docker Content Trust (DCT)**, il convient de vérifier que la valeur de la variable **DOCKER_CONTENT_TRUST** est **1** :
@@ Ligne 836: / Ligne 1532: @@
 </code>
-====DCT et la commande docker pull====
+====9.2 - DCT et la commande docker pull====
 Afin d'utiliser un registry privé du Docker Hub, il est nécessaire de se connecter :
@@ Ligne 843: / Ligne 1539: @@
 root@manager:~# docker login
 Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
-Username: i2tch
+Username: <votre_compte>
-Password:
+Password: <votre_mot_de_passe>
 WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
 Configure a credential helper to remove this warning. See
@@ Ligne 943: / Ligne 1639: @@
 </code>
-====DCT et la commande docker push====
+====9.3 - DCT et la commande docker push====
 Pour envoyer l'image dont l'IMAGE ID est **965ea09ff2eb** dans le registry privé, le tag de l'image doit être modifié :
 <code>
-root@manager:~# docker image tag alpine:latest i2tch/docker:alpine
+root@manager:~# docker image tag alpine:latest <votre_compte>/docker:alpine
 </code>
-L'image dont l'IMAGE ID est **965ea09ff2eb** a maintenant deux tags **alpine:latest** et **i2tch/docker:alpine** :
+L'image dont l'IMAGE ID est **965ea09ff2eb** a maintenant deux tags **alpine:latest** et **<votre_compte>/docker:alpine** :
 <code>
 root@manager:~# docker image ls
-REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
+REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
-ubuntu              latest              775349758637        9 days ago          64.2MB
+ubuntu                 latest              775349758637        9 days ago          64.2MB
-nginx               latest              540a289bab6c        2 weeks ago         126MB
+nginx                  latest              540a289bab6c        2 weeks ago         126MB
-i2tch/docker        alpine              965ea09ff2eb        2 weeks ago         5.55MB
+<votre_compte>/docker  alpine              965ea09ff2eb        2 weeks ago         5.55MB
-alpine              latest              965ea09ff2eb        2 weeks ago         5.55MB
+alpine                 latest              965ea09ff2eb        2 weeks ago         5.55MB
-mysql               latest              c8ee894bd2bd        3 weeks ago         456MB
+mysql                  latest              c8ee894bd2bd        3 weeks ago         456MB
-centos              latest              0f3e07c0138f        5 weeks ago         220MB
+centos                 latest              0f3e07c0138f        5 weeks ago         220MB
 </code>
@@ Ligne 970: / Ligne 1666: @@
 <code>
-root@manager:~# docker push i2tch/docker:alpine
+root@manager:~# docker push <votre_compte>/docker:alpine
-The push refers to repository [docker.io/i2tch/docker]
+The push refers to repository [docker.io/<votre_compte>/docker]
 cae8ab23bf: Mounted from library/alpine
 alpine: digest: sha256:e4355b66995c96b4b468159fc5c7e3540fcef961189ca13fee877798649f531a size: 528
@@ Ligne 985: / Ligne 1681: @@
 Enter passphrase for new repository key with ID 168c754: fenestros
 Repeat passphrase for new repository key with ID 168c754: fenestros
-Finished initializing "docker.io/i2tch/docker"
+Finished initializing "docker.io/<votre_compte>/docker"
-Successfully signed docker.io/i2tch/docker:alpine
+Successfully signed docker.io/<votre_compte>/docker:alpine
 </code>
@@ Ligne 1027: / Ligne 1723: @@
 </code>
-====DCT et la commande docker build====
+====9.4 - DCT et la commande docker build====
 L'exemple suivant démontre un Dockerfile qui référence une image parente non signée :
@@ Ligne 1040: / Ligne 1736: @@
 </code>
-Lors du build de l'image **i2tch/docker:nottrusted** qui utilise ce Dockerfile, une erreur est retournée car sa création n'est pas conforme à l'utilisation de DCT :
+Lors du build de l'image **<votre_compte>/docker:nottrusted** qui utilise ce Dockerfile, une erreur est retournée car sa création n'est pas conforme à l'utilisation de DCT :
 <code>
-root@manager:~/nottrusted# docker build -t i2tch/docker:nottrusted .
+root@manager:~/nottrusted# docker build -t <votre_compte>/docker:nottrusted .
 Sending build context to Docker daemon
@@ Ligne 1049: / Ligne 1745: @@
 </code>
-L'utilisation de l'option **--disable-content-trust** permet la construction de l'image **i2tch/docker:nottrusted** :
+L'utilisation de l'option **--disable-content-trust** permet la construction de l'image **<votre_compte>/docker:nottrusted** :
 <code>
-root@manager:~/nottrusted# docker build --disable-content-trust -t i2tch/docker:nottrusted .
+root@manager:~/nottrusted# docker build --disable-content-trust -t <votre_compte>/docker:nottrusted .
 Sending build context to Docker daemon  2.048kB
 Step 1/2 : FROM docker/trusttest:latest
@@ Ligne 1068: / Ligne 1764: @@
  ---> 686e85ee76b8
 Successfully built 686e85ee76b8
-Successfully tagged i2tch/docker:nottrusted
+Successfully tagged <votre_compte>/docker:nottrusted
 </code>
-Lors du push de l'image **i2tch/docker:nottrusted** vers le repositry distant, celle-ci est **signée** :
+Lors du push de l'image **<votre_compte>/docker:nottrusted** vers le repositry distant, celle-ci est **signée** :
 <code>
-root@manager:~/nottrusted# docker push i2tch/docker:nottrusted
+root@manager:~/nottrusted# docker push <votre_compte>/docker:nottrusted
-The push refers to repository [docker.io/i2tch/docker]
+The push refers to repository [docker.io/<votre_compte>/docker]
 f70bf18a086: Layer already exists
 c22f7bc058a9: Mounted from docker/trusttest
@@ Ligne 1081: / Ligne 1777: @@
 Signing and pushing trust metadata
 Enter passphrase for repository key with ID 168c754: fenestros
-Successfully signed docker.io/i2tch/docker:nottrusted
+Successfully signed docker.io/<votre_compte>/docker:nottrusted
 </code>
 <WRAP center round important 60%>
-**Important** : Notez l'utilisation de la même root key que lors du push de l'image **i2tch/docker:alpine** car il s'agit du même repositry.
+**Important** : Notez l'utilisation de la même root key que lors du push de l'image **<votre_compte>/docker:alpine** car il s'agit du même repositry.
 </WRAP>
 ===Créer un deuxième Repositry===
-Par contre en modifiant le tag de l'image **i2tch/docker:nottrusted** à **i2tch/otherimage:latest**, un autre repositry sera créé lors du push de l'image renommée :
+Par contre en modifiant le tag de l'image **<votre_compte>/docker:nottrusted** à **<votre_compte>/otherimage:latest**, un autre repositry sera créé lors du push de l'image renommée :
 <code>
-root@manager:~/nottrusted# docker tag i2tch/docker:nottrusted i2tch/otherimage:latest
+root@manager:~/nottrusted# docker tag <votre_compte>/docker:nottrusted <votre_compte>/otherimage:latest
 root@manager:~/nottrusted# docker images
-REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
+REPOSITORY                   TAG                 IMAGE ID            CREATED             SIZE
-i2tch/docker        nottrusted          686e85ee76b8        9 minutes ago       5.03MB
+<votre_compte>/docker        nottrusted          686e85ee76b8        9 minutes ago       5.03MB
-i2tch/otherimage    latest              686e85ee76b8        9 minutes ago       5.03MB
+<votre_compte>/otherimage    latest              686e85ee76b8        9 minutes ago       5.03MB
-ubuntu              latest              775349758637        9 days ago          64.2MB
+ubuntu                       latest              775349758637        9 days ago          64.2MB
-nginx               latest              540a289bab6c        2 weeks ago         126MB
+nginx                        latest              540a289bab6c        2 weeks ago         126MB
-i2tch/docker        alpine              965ea09ff2eb        2 weeks ago         5.55MB
+<votre_compte>/docker        alpine              965ea09ff2eb        2 weeks ago         5.55MB
-alpine              latest              965ea09ff2eb        2 weeks ago         5.55MB
+alpine                       latest              965ea09ff2eb        2 weeks ago         5.55MB
-mysql               latest              c8ee894bd2bd        3 weeks ago         456MB
+mysql                        latest              c8ee894bd2bd        3 weeks ago         456MB
-centos              latest              0f3e07c0138f        5 weeks ago         220MB
+centos                       latest              0f3e07c0138f        5 weeks ago         220MB
-docker/trusttest    latest              cc7629d1331a        4 years ago         5.03MB
+docker/trusttest             latest              cc7629d1331a        4 years ago         5.03MB
-root@manager:~/nottrusted# docker push docker.io/i2tch/otherimage:latest
+root@manager:~/nottrusted# docker push docker.io/<votre_compte>/otherimage:latest
-The push refers to repository [docker.io/i2tch/otherimage]
+The push refers to repository [docker.io/<votre_compte>/otherimage]
-f70bf18a086: Mounted from i2tch/docker
+f70bf18a086: Mounted from <votre_compte>/docker
-c22f7bc058a9: Mounted from i2tch/docker
+c22f7bc058a9: Mounted from <votre_compte>/docker
 latest: digest: sha256:1183c62a5d31e202b5f5f528e9e7cdc36140aa3212c938e1d471c6b3b59f01bc size: 734
 Signing and pushing trust metadata
@@ Ligne 1115: / Ligne 1811: @@
 Enter passphrase for new repository key with ID 7b13d02: fenestros
 Repeat passphrase for new repository key with ID 7b13d02: fenestros
-Finished initializing "docker.io/i2tch/otherimage"
+Finished initializing "docker.io/<votre_compte>/otherimage"
-Successfully signed docker.io/i2tch/otherimage:latest
+Successfully signed docker.io/<votre_compte>/otherimage:latest
 </code>
 <WRAP center round important 60%>
-**Important** : Notez la création d'une deuxième repositry key (ID 7b13d02 au lieu de ID 168c754) lors du push de l'image **i2tch/otherimage:latest** car il s'agit d'un autre repositry.
+**Important** : Notez la création d'une deuxième repositry key (ID 7b13d02 au lieu de ID 168c754) lors du push de l'image **<votre_compte>/otherimage:latest** car il s'agit d'un autre repositry.
 </WRAP>
@@ Ligne 1136: / Ligne 1832: @@
 <code>
-root@manager:~/nottrusted# docker trust inspect i2tch/docker:alpine
+root@manager:~/nottrusted# docker trust inspect <votre_compte>/docker:alpine
 [
     {
-        "Name": "i2tch/docker:alpine",
+        "Name": "<votre_compte>/docker:alpine",
         "SignedTags": [
             {
@@ Ligne 1170: / Ligne 1866: @@
     }
 ]
-root@manager:~/nottrusted# docker trust inspect i2tch/docker:nottrusted
+root@manager:~/nottrusted# docker trust inspect <votre_compte>/docker:nottrusted
 [
     {
-        "Name": "i2tch/docker:nottrusted",
+        "Name": "<votre_compte>/docker:nottrusted",
         "SignedTags": [
             {
@@ Ligne 1211: / Ligne 1907: @@
 <code>
-root@manager:~/nottrusted# docker trust inspect i2tch/otherimage:latest
+root@manager:~/nottrusted# docker trust inspect <votre_compte>/otherimage:latest
 [
     {
-        "Name": "i2tch/otherimage:latest",
+        "Name": "<votre_compte>/otherimage:latest",
         "SignedTags": [
             {
@@ Ligne 1256: / Ligne 1952: @@
 <code>
-root@manager:~# docker trust revoke i2tch/docker:alpine
+root@manager:~# docker trust revoke <votre_compte>/docker:alpine
 Enter passphrase for repository key with ID 168c754:
-Successfully deleted signature for i2tch/docker:alpine
+Successfully deleted signature for <votre_compte>/docker:alpine
-root@manager:~# docker trust inspect i2tch/docker:alpine
+root@manager:~# docker trust inspect <votre_compte>/docker:alpine
 [
     {
-        "Name": "i2tch/docker:alpine",
+        "Name": "<votre_compte>/docker:alpine",
         "SignedTags": [],
         "Signers": [],
@@ Ligne 1287: / Ligne 1983: @@
 </code>
-=====LAB #15 - Sécurisation du Socket du Daemon Docker=====
+<WRAP center round important>
+**Important** : Il existe un autre mécanisme de signatures cryptographiques qui permet de certifier le contenu des images mises à disposition sur une Registry. Appelé **Notary**, ce système a été développé par la communauté Docker et intègre une partie de la spécification de **[[https://theupdateframework.io/|The Update Framework]]** (TUF). Pour plus d'informations, consultez cet **[[https://blog.octo.com/la-signature-dimages-docker-sur-une-registry-avec-notary/#:~:text=Notary%20est%20un%20m%C3%A9canisme%20de,environnement%20de%20production%20par%20exemple|article]]**.
+</WRAP>
+=====LAB #10 - Sécurisation du Socket du Daemon Docker=====
 Par défaut le daemon Docker peut être contacté en utilisant un socket Unix local ce qui implique qu'il faut une connexion SSH vers l'hôte Docker. Docker peut cependant utiliser un socket http.
@@ Ligne 1305: / Ligne 2005: @@
 </code>
-====Création du Certificat de l'Autorité de Certification====
+====10.1 - Création du Certificat de l'Autorité de Certification====
 Commencez par créer une clef privée **ca-key.pem** pour le CA :
@@ Ligne 1340: / Ligne 2040: @@
 </code>
-====Création du Certificat du Serveur Hôte du Daemon Docker====
+====10.2 - Création du Certificat du Serveur Hôte du Daemon Docker====
 Les clefs du CA ayant été créées, créez une clef **server-key.pem** pour le serveur hôte du daemon Docker :
@@ Ligne 1363: / Ligne 2063: @@
 <code>
-root@manager:~# echo subjectAltName = DNS:`echo $HOSTNAME`,IP:10.0.2.15,IP:127.0.0.1 >> extfile.cnf
+root@manager:~# echo subjectAltName = DNS:`echo $HOSTNAME`,IP:10.0.2.62,IP:127.0.0.1 >> extfile.cnf
 </code>
@@ Ligne 1376: / Ligne 2076: @@
 <code>
 root@manager:~# cat extfile.cnf
-subjectAltName = DNS:manager.i2tch.loc,IP:10.0.2.15,IP:127.0.0.1
+subjectAltName = DNS:manager.i2tch.loc,IP:10.0.2.62,IP:127.0.0.1
 extendedKeyUsage = serverAuth
 </code>
@@ Ligne 1390: / Ligne 2090: @@
 </code>
-====Création du Certificat du Client====
+====10.3 - Création du Certificat du Client====
 Créez ensuite la clef privée **key.pem** du client qui se connectera au daemon à partir du réseau :
@@ Ligne 1402: / Ligne 2102: @@
 </code>
-A défaut d'une entrée dans le serveur DNS, créez une entrée pour le client dans le fichier **/etc/hosts** du serveur :
+Modifiez l'entrée pour l'adresse 10.0.2.61 dans le fichier **/etc/hosts** du manager :
 <code>
@@ Ligne 1408: / Ligne 2108: @@
 root@manager:~# cat /etc/hosts
 .0.0.1	localhost
-.0.1.1	manager.i2tch.loc	manager
+.0.2.60	debian9.i2tch.loc	debian9
-.0.2.15	manager.i2tch.loc	manager
+.0.2.61	myregistry.i2tch.loc    myregistry
-.0.2.4	worker1.i2tch.loc	worker1
+.0.2.62	manager.i2tch.loc	manager
-.0.2.5	worker2.i2tch.loc	worker2
+.0.2.63	worker1.i2tch.loc	worker1
-.0.2.9	client.i2tch.loc	client
+.0.2.64	worker2.i2tch.loc	worker2
 # The following lines are desirable for IPv6 capable hosts
@@ Ligne 1423: / Ligne 2123: @@
 <code>
-root@manager:~# openssl req -subj '/CN=client.i2tch.loc' -new -key key.pem -out client.csr
+root@manager:~# openssl req -subj '/CN=myregistry.i2tch.loc' -new -key key.pem -out client.csr
 </code>
@@ Ligne 1437: / Ligne 2137: @@
 root@manager:~# openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile-client.cnf
 Signature ok
-subject=CN = client.i2tch.loc
+subject=CN = myregistry.i2tch.loc
 Getting CA Private Key
 Enter pass phrase for ca-key.pem:fenestros
@@ Ligne 1501: / Ligne 2201: @@
 </code>
-====Démarrage du Daemon Docker avec une Invocation Directe====
+====10.4 - Démarrage du Daemon Docker avec une Invocation Directe====
 Arrêtez et désactivez le service Docker :
@@ Ligne 1564: / Ligne 2264: @@
 </code>
-====Configuration du Client====
+====10.5 - Configuration du Client====
-Transférez ensuite le certificat du CA ainsi que le certificat et la clef privée du client vers la VM **Debian_9** :
+Transférez ensuite le certificat du CA ainsi que le certificat et la clef privée du client vers la VM **debian91** :
 <code>
-root@manager:~# scp ca.pem key.pem cert.pem trainee@10.0.2.9:/home/trainee/
+root@manager:~# scp ca.pem key.pem cert.pem trainee@10.0.2.61:/home/trainee/
-The authenticity of host '10.0.2.9 (10.0.2.9)' can't be established.
+The authenticity of host '10.0.2.61 (10.0.2.61)' can't be established.
 ECDSA key fingerprint is SHA256:sEfHBv9azmK60cjqF/aJgUc9jg56slNaZQdAUcvBOvE.
 Are you sure you want to continue connecting (yes/no)? yes
-Warning: Permanently added '10.0.2.9' (ECDSA) to the list of known hosts.
+Warning: Permanently added '10.0.2.61' (ECDSA) to the list of known hosts.
-trainee@10.0.2.9's password:
+trainee@10.0.2.61's password:
 ca.pem                                                                                                                                 100% 2163   917.8KB/s   00:00
 key.pem                                                                                                                                100% 3243     3.0MB/s   00:00
@@ Ligne 1580: / Ligne 2280: @@
 </code>
-Modifiez le nom d'hôte du client ainsi que le fichier **/etc/hosts** :
+Lancez la commande **docker version** sur la VM **debian91** :
 <code>
-trainee@debian9:~$ hostname
+trainee@myregistry:~$ docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=manager.i2tch.loc:2376 version
-debian9
-trainee@debian9:~$ su -
-Mot de passe : fenestros
-root@debian9:~# hostname client.i2tch.loc
-root@debian9:~#
-root@debian9:~# vi /etc/hosts
-root@debian9:~# cat /etc/hosts
-.0.0.1	localhost
-.0.1.1	client.i2tch.loc	client
-.0.2.9	client.i2tch.loc	client
-.0.2.15	manager.i2tch.loc	manager
-# The following lines are desirable for IPv6 capable hosts
-::1     localhost ip6-localhost ip6-loopback
-ff02::1 ip6-allnodes
-ff02::2 ip6-allrouters
-</code>
-Déconnectez-vous du client Debian_9 :
-<code>
-root@debian9:~# exit
-déconnexion
-trainee@debian9:~$ exit
-déconnexion
-</code>
-Connectez-vous de nouveau à la VM Debian_9 et lancez la commande **docker version** sur le serveur :
-<code>
-trainee@client:~$ docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=manager.i2tch.loc:2376 version
 Client: Docker Engine - Community
  Version:           19.03.4
@@ Ligne 1644: / Ligne 2313: @@
 </code>
-Afin de faciliter l'utilisation des commandes sur le serveur à partir du client, créez le répertoire **~/.docker** :
+Afin de faciliter l'utilisation des commandes sur le serveur à partir de myregistry, créez le répertoire **~/.docker** :
 <code>
-trainee@client:~$ mkdir -pv ~/.docker
+trainee@myregistry:~$ mkdir -pv ~/.docker
 mkdir: création du répertoire '/home/trainee/.docker'
 </code>
@@ Ligne 1654: / Ligne 2323: @@
 <code>
-trainee@client:~$ cp -v {ca,cert,key}.pem ~/.docker
+trainee@myregistry:~$ cp -v {ca,cert,key}.pem ~/.docker
 'ca.pem' -> '/home/trainee/.docker/ca.pem'
 'cert.pem' -> '/home/trainee/.docker/cert.pem'
@@ Ligne 1663: / Ligne 2332: @@
 <code>
-trainee@client:~$ export DOCKER_HOST=tcp://manager.i2tch.loc:2376 DOCKER_TLS_VERIFY=1
+trainee@myregistry:~$ export DOCKER_HOST=tcp://manager.i2tch.loc:2376 DOCKER_TLS_VERIFY=1
 </code>
@@ Ligne 1669: / Ligne 2338: @@
 <code>
-trainee@client:~$ docker image ls
+trainee@myregistry:~$ docker image ls
 REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
 i2tch/docker        nottrusted          686e85ee76b8        19 hours ago        5.03MB
@@ Ligne 1682: / Ligne 2351: @@
 </code>
-=====Arrêter les Machines Virtuelles=====
+-----
-====Formations en FFP====
+Copyright © 2022 Hugh Norris.
-Utilisez l'interface graphique de VirtualBox et arrêtez les machines virtuelles **Manager**, **Worker1**, **Worker2** et **Debian_9_1**.
-Restaurez ensuite chaque machine virtuelle vers son état d'origine en revenant à **snapshot1**.
-====Formations en FAD====
-Utilisez les commandes suivantes pour arrêter les machines virtuelles **Manager**, **Worker1**, **Worker2** et **Debian_9_1** :
-<code>
-desktop@server16:~$ VBoxManage controlvm Manager poweroff
-%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
-desktop@server16:~$ VBoxManage controlvm Worker1 poweroff
-%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
-desktop@server16:~$ VBoxManage controlvm Worker2 poweroff
-%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
-desktop@server16:~$ VBoxManage controlvm Debian_9_1 poweroff
-%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
-</code>
-Restaurez l'état d'origine des machines virtuelles :
-<code>
-desktop@server16:~$ VBoxManage snapshot Manager restorecurrent
-Restoring snapshot 'snapshot1' (22df4e22-876a-4e94-88a8-8422a3a6b158)
-%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
-desktop@server16:~$ VBoxManage snapshot Worker1 restorecurrent
-Restoring snapshot 'snapshot1' (22df4e22-876a-4e94-88a8-8422a3a6b158)
-%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
-desktop@server16:~$ VBoxManage snapshot Worker2 restorecurrent
-Restoring snapshot 'snapshot1' (22df4e22-876a-4e94-88a8-8422a3a6b158)
-%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
-desktop@server16:~$ VBoxManage snapshot Debian_9_1 restorecurrent
-Restoring snapshot 'snapshot1' (22df4e22-876a-4e94-88a8-8422a3a6b158)
-%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
-</code>
------
-<html>
-<div align="center">
-Copyright © 2020 Hugh NORRIS
-</div>
-</html>

Piste : • LCF207 - Gestion des Processus • DOF608 - Validation de la Formation • Préparation à l'Examen LPIC 102-500 • LCF204 - Gestion des Disques, des Systèmes de Fichiers et du Swap • LCF506 - Gestion de l'Archivage et de la Compression • LCF300 - Présentation de la Formation • LCF400 - Présentation de la Formation • LCF210 - Gestion du Démarrage et de l'Arrêt du Système • RH12406 - User Management • RH12409 - Gestion de l'Archivage et de la Compression

Différences

Recherche

Imprimer/exporter

Menu