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

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
elearning:workbooks:docker2:drf03 [2020/12/11 05:48] – adminelearning:workbooks:docker2:drf03 [2021/12/29 10:32] (Version actuelle) – admin
Ligne 1: Ligne 1:
 +
 ~~PDF:LANDSCAPE~~ ~~PDF:LANDSCAPE~~
  
-Version : **2020.01**+Version : **2022.01**
  
 Dernière mise-à-jour : ~~LASTMOD~~ Dernière mise-à-jour : ~~LASTMOD~~
Ligne 11: Ligne 12:
   * **DOF204 - Gestion de la Sécurité de Docker**   * **DOF204 - Gestion de la Sécurité de Docker**
     * Contenu du Module     * Contenu du Module
-    * LAB #1 - Création d'un Utilisateur de Confiance pour Contrôler le Daemon Docker +    * LAB #1 - Travailler avec les CGroups 
-    * LAB #2 - Le Script docker-bench-security.sh +      * 1.1 - Présentation des Namespaces 
-    * LAB #3 - Sécurisation de la Configuration de l'Hôte Docker +      * 1.2 - Présentation des CGroups 
-      * 3.1 - [WARN] 1.2.1 - Ensure a separate partition for containers has been created +      * 1.3 - Limitation de la Mémoire 
-      * 3.2 - [WARN] 1.2.3 - Ensure auditing is configured for the Docker daemon +      * 1.4 - Le Paquet cgroup-tools 
-    * LAB #4 - Sécurisation de la Configuration du daemon Docker +        * La commande cgcreate 
-      * 4.1 - [WARN] 2.1 - Ensure network traffic is restricted between containers on the default bridge +        * La Commande cgexec 
-      * 4.2 - [WARN] 2.8 - Enable user namespace support +        * La Commande cgdelete 
-      * 4.3 - [WARN] 2.11 - Ensure that authorization for Docker client commands is enabled +        * Le Fichier /etc/cgconfig.conf 
-      * 4.4 - [WARN] 2.12 - Ensure centralized and remote logging is configured +    * LAB #2 - Utilisation des Docker Secrets 
-      * 4.5 - [WARN] 2.14 - Ensure Userland Proxy is Disabled +    * LAB #3 - Création d'un Utilisateur de Confiance pour Contrôler le Daemon Docker 
-      * 4.6 - [WARN] 2.17 - Ensure containers are restricted from acquiring new privileges +    * LAB #4 - Le Script docker-bench-security.sh 
-      * 4.7 - Le Fichier /etc/docker/daemon.json +    * LAB #5 - Sécurisation de la Configuration de l'Hôte Docker 
-    * LAB #5 - Sécurisation des Images et les Fichiers de Construction +      * 5.1 - [WARN] 1.2.1 - Ensure a separate partition for containers has been created 
-      * 5.1 - [WARN] 4.1 - Ensure a user for the container has been created +      * 5.2 - [WARN] 1.2.3 - Ensure auditing is configured for the Docker daemon 
-      * 5.2 - [WARN] 4.5 - Ensure Content trust for Docker is Enabled +    * LAB #6 - Sécurisation de la Configuration du daemon Docker 
-      * 5.3 - [WARN] 4.6 - Ensure that HEALTHCHECK instructions have been added to container images +      * 6.1 - [WARN] 2.1 - Ensure network traffic is restricted between containers on the default bridge 
-    * LAB #6 - Sécurisation du Container Runtime +      * 6.2 - [WARN] 2.8 - Enable user namespace support 
-      * 6.1 - [WARN] 5.1 - Ensure AppArmor Profile is Enabled +      * 6.3 - [WARN] 2.11 - Ensure that authorization for Docker client commands is enabled 
-      * 6.2 - [WARN] 5.2 - Ensure SELinux security options are set, if applicable +      * 6.4 - [WARN] 2.12 - Ensure centralized and remote logging is configured 
-      * 6.3 - [WARN] 5.10 - Ensure memory usage for container is limited +      * 6.5 - [WARN] 2.14 - Ensure Userland Proxy is Disabled 
-      * 6.4 - [WARN] 5.11 - Ensure CPU priority is set appropriately on the container +      * 6.6 - [WARN] 2.17 - Ensure containers are restricted from acquiring new privileges 
-      * 6.5 - [WARN] 5.12 - Ensure the container's root filesystem is mounted as read only +      * 6.7 - Le Fichier /etc/docker/daemon.json 
-      * 6.6 - [WARN] 5.14 - Ensure 'on-failure' container restart policy is set to '5' +    * LAB #7 - Sécurisation des Images et les Fichiers de Construction 
-      * 6.7 - [WARN] 5.25 - Ensure the container is restricted from acquiring additional privileges +      * 7.1 - [WARN] 4.1 - Ensure a user for the container has been created 
-      * 6.8 - [WARN] 5.26 - Ensure container health is checked at runtime +      * 7.2 - [WARN] 4.5 - Ensure Content trust for Docker is Enabled 
-      * 6.9 - [WARN] 5.28 - Ensure PIDs cgroup limit is used +      * 7.3 - [WARN] 4.6 - Ensure that HEALTHCHECK instructions have been added to container images 
-    * LAB #7 - Sécurisation des Images avec Docker Content Trust +    * LAB #8 - Sécurisation du Container Runtime 
-      * 7.1 - DOCKER_CONTENT_TRUST +      * 8.1 - [WARN] 5.1 - Ensure AppArmor Profile is Enabled 
-      * 7.2 - DCT et la commande docker pull+      * 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         * L'option disable-content-trust
-      * 7.3 - DCT et la commande docker push +      * 9.3 - DCT et la commande docker push 
-      * 7.4 - DCT et la commande docker build+      * 9.4 - DCT et la commande docker build
         * Créer un deuxième Repositry         * Créer un deuxième Repositry
         * Supprimer une Signature         * Supprimer une Signature
-    * LAB #8 - Sécurisation du Socket du Daemon Docker +    * LAB #10 - Sécurisation du Socket du Daemon Docker 
-      * 8.1 - Création du Certificat de l'Autorité de Certification +      * 10.1 - Création du Certificat de l'Autorité de Certification 
-      * 8.2 - Création du Certificat du Serveur Hôte du Daemon Docker +      * 10.2 - Création du Certificat du Serveur Hôte du Daemon Docker 
-      * 8.3 - Création du Certificat du Client +      * 10.3 - Création du Certificat du Client 
-      * 8.4 - Démarrage du Daemon Docker avec une Invocation Directe +      * 10.4 - Démarrage du Daemon Docker avec une Invocation Directe 
-      * 8.5 - Configuration du Client+      * 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. 
 + 
 +6 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 
 +6: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 
 +6: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 
 +319488 
 +</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 
 +4096 
 +</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 
 +36864 
 +root@debian9:~# cat /sys/fs/cgroup/cpu/helloworld2/cpu.shares 
 +100 
 +</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 - 
 +5lx4zydpfocwgpdto0yy1jod9 
 +</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 
 +5lx4zydpfocwgpdto0yy1jod9   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 #1 - 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. 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 78: Ligne 753:
 </code> </code>
  
-=====LAB #2 - 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/]]. 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 146: Ligne 821:
   * **[NOTE]** : Vous informe d'un **best practice**.   * **[NOTE]** : Vous informe d'un **best practice**.
  
-=====LAB #3 - 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 : 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 182: Ligne 857:
 Les problèmes de sécurité qu'il convient à résoudre sont indiqués par les annotations **[WARN]**. Les problèmes de sécurité qu'il convient à résoudre sont indiqués par les annotations **[WARN]**.
  
-====3.1 - [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é. 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é.
  
-====3.2 - [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> <file>
Ligne 286: Ligne 961:
 </code> </code>
  
-=====LAB #4 - 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 : 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 317: Ligne 992:
 Les problèmes de sécurité qu'il convient à résoudre sont indiqués par les annotations **[WARN]**. Les problèmes de sécurité qu'il convient à résoudre sont indiqués par les annotations **[WARN]**.
  
-====4.1 - [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. 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 323: Ligne 998:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/userguide/networking/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/userguide/networking/|page]]**.
  
-====4.2 - [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"**. 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 329: Ligne 1004:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/security/userns-remap/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/security/userns-remap/|page]]**.
  
-====4.3 - [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) 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 335: Ligne 1010:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/extend/plugins_authorization/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/extend/plugins_authorization/|page]]**.
  
-====4.4 - [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. 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 341: Ligne 1016:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/admin/logging/overview/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/admin/logging/overview/|page]]**.
  
-====4.5 - [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 : Il existe deux méthodes pour qu'un conteneur puisse router vers l'extérieur :
Ligne 352: Ligne 1027:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/userguide/networking/default_network/binding/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/userguide/networking/default_network/binding/|page]]**.
  
-====4.6 - [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**. 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 358: Ligne 1033:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/userguide/networking/default_network/binding/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/userguide/networking/default_network/binding/|page]]**.
  
-====4.7 - Le Fichier /etc/docker/daemon.json ====+====6.7 - Le Fichier /etc/docker/daemon.json ====
  
 Créez le fichier **/etc/docker/daemon.json** :  Créez le fichier **/etc/docker/daemon.json** : 
Ligne 411: Ligne 1086:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file/|page]]**.
  
-=====LAB #5 - 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 : Créez le conteneur mysql :
Ligne 463: Ligne 1138:
 </code> </code>
  
-====5.1 - [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]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/security/security/|page]]**.
  
-====5.2 - [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. 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 517: Ligne 1192:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/security/trust/content_trust/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/security/trust/content_trust/|page]]**.
  
-====5.3 - [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.  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 531: Ligne 1206:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/reference/builder/#healthcheck|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/reference/builder/#healthcheck|page]]**.
  
-=====LAB #6 - 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 : 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 586: Ligne 1261:
 Les problèmes de sécurité qu'il convient à résoudre sont indiqués par les annotations **[WARN]**. Les problèmes de sécurité qu'il convient à résoudre sont indiqués par les annotations **[WARN]**.
  
-====6.1 - [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. Cet avertissement est présent parce que le conteneur n'utilise pas AppArmor.
Ligne 592: Ligne 1267:
 Pour plus d'informations, consultez cette **[[https://cloud.google.com/container-optimized-os/docs/how-to/secure-apparmor|page]]**. Pour plus d'informations, consultez cette **[[https://cloud.google.com/container-optimized-os/docs/how-to/secure-apparmor|page]]**.
  
-====6.2 - [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. Cet avertissement est présent parce que le conteneur n'utilise pas SELinux.
Ligne 598: 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]]**. 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]]**.
  
-====6.3 - [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 : Cet avertissement est du au fait que les conteneurs ont automatiquement accès à la totalité de la RAM de l'hôte Docker :
Ligne 631: Ligne 1306:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/config/containers/resource_constraints/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/config/containers/resource_constraints/|page]]**.
  
-====6.4 - [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**. 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 639: Ligne 1314:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/config/containers/resource_constraints/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/config/containers/resource_constraints/|page]]**.
  
-====6.5 - [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. 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 708: Ligne 1383:
 </WRAP> </WRAP>
  
-====6.6 - [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 : 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 716: Ligne 1391:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/config/containers/start-containers-automatically/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/config/containers/start-containers-automatically/|page]]**.
  
-====6.7 - [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** : Pour complémenter la configuration précédemment mise en place, il convient de lancer le conteneur en utilisant l'option **--security-opt** :
Ligne 724: Ligne 1399:
 Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/reference/run/|page]]**. Pour plus d'informations, consultez cette **[[https://docs.docker.com/engine/reference/run/|page]]**.
  
-====6.8 - [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. Voir l'avertissement 4.6.
  
-====6.9 - [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 : 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 830: Ligne 1505:
 </code> </code>
  
-=====LAB #7 - 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é**. **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 840: Ligne 1515:
 Pour plus d'information concernant DCT, consultez cette **[[https://docs.docker.com/engine/security/trust/content_trust/|page]]**. Pour plus d'information concernant DCT, consultez cette **[[https://docs.docker.com/engine/security/trust/content_trust/|page]]**.
  
-====7.1 - 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** : Pour utiliser **Docker Content Trust (DCT)**, il convient de vérifier que la valeur de la variable **DOCKER_CONTENT_TRUST** est **1** :
Ligne 857: Ligne 1532:
 </code> </code>
  
-====7.2 - 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 : Afin d'utiliser un registry privé du Docker Hub, il est nécessaire de se connecter :
Ligne 864: Ligne 1539:
 root@manager:~# docker login 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. 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. WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
 Configure a credential helper to remove this warning. See Configure a credential helper to remove this warning. See
Ligne 964: Ligne 1639:
 </code> </code>
  
-====7.3 - 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é : Pour envoyer l'image dont l'IMAGE ID est **965ea09ff2eb** dans le registry privé, le tag de l'image doit être modifié :
  
 <code> <code>
-root@manager:~# docker image tag alpine:latest i2tch/docker:alpine+root@manager:~# docker image tag alpine:latest <votre_compte>/docker:alpine
 </code> </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> <code>
 root@manager:~# docker image ls 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> </code>
  
Ligne 991: Ligne 1666:
  
 <code> <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]
 77cae8ab23bf: Mounted from library/alpine  77cae8ab23bf: Mounted from library/alpine 
 alpine: digest: sha256:e4355b66995c96b4b468159fc5c7e3540fcef961189ca13fee877798649f531a size: 528 alpine: digest: sha256:e4355b66995c96b4b468159fc5c7e3540fcef961189ca13fee877798649f531a size: 528
Ligne 1006: Ligne 1681:
 Enter passphrase for new repository key with ID 168c754: fenestros Enter passphrase for new repository key with ID 168c754: fenestros
 Repeat 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> </code>
  
Ligne 1048: Ligne 1723:
 </code> </code>
  
-====7.4 - 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 : L'exemple suivant démontre un Dockerfile qui référence une image parente non signée :
Ligne 1061: Ligne 1736:
 </code> </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> <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  Sending build context to Docker daemon 
  
Ligne 1070: Ligne 1745:
 </code> </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> <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 Sending build context to Docker daemon  2.048kB
 Step 1/2 : FROM docker/trusttest:latest Step 1/2 : FROM docker/trusttest:latest
Ligne 1089: Ligne 1764:
  ---> 686e85ee76b8  ---> 686e85ee76b8
 Successfully built 686e85ee76b8 Successfully built 686e85ee76b8
-Successfully tagged i2tch/docker:nottrusted+Successfully tagged <votre_compte>/docker:nottrusted
 </code> </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> <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]
 5f70bf18a086: Layer already exists  5f70bf18a086: Layer already exists 
 c22f7bc058a9: Mounted from docker/trusttest  c22f7bc058a9: Mounted from docker/trusttest 
Ligne 1102: Ligne 1777:
 Signing and pushing trust metadata Signing and pushing trust metadata
 Enter passphrase for repository key with ID 168c754: fenestros 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> </code>
  
 <WRAP center round important 60%> <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> </WRAP>
  
 ===Créer un deuxième Repositry=== ===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> <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 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] 
-5f70bf18a086: Mounted from i2tch/docker  +5f70bf18a086: Mounted from <votre_compte>/docker  
-c22f7bc058a9: Mounted from i2tch/docker +c22f7bc058a9: Mounted from <votre_compte>/docker 
 latest: digest: sha256:1183c62a5d31e202b5f5f528e9e7cdc36140aa3212c938e1d471c6b3b59f01bc size: 734 latest: digest: sha256:1183c62a5d31e202b5f5f528e9e7cdc36140aa3212c938e1d471c6b3b59f01bc size: 734
 Signing and pushing trust metadata Signing and pushing trust metadata
Ligne 1136: Ligne 1811:
 Enter passphrase for new repository key with ID 7b13d02: fenestros Enter passphrase for new repository key with ID 7b13d02: fenestros
 Repeat 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> </code>
  
 <WRAP center round important 60%> <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> </WRAP>
  
Ligne 1157: Ligne 1832:
  
 <code> <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": [         "SignedTags": [
             {             {
Ligne 1191: 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": [         "SignedTags": [
             {             {
Ligne 1232: Ligne 1907:
  
 <code> <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": [         "SignedTags": [
             {             {
Ligne 1277: Ligne 1952:
  
 <code> <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:  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": [],         "SignedTags": [],
         "Signers": [],         "Signers": [],
Ligne 1308: Ligne 1983:
 </code> </code>
  
-=====LAB #8 - 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. 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 1326: Ligne 2005:
 </code> </code>
  
-====8.1 - 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 : Commencez par créer une clef privée **ca-key.pem** pour le CA :
Ligne 1361: Ligne 2040:
 </code> </code>
  
-====8.2 - 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 : Les clefs du CA ayant été créées, créez une clef **server-key.pem** pour le serveur hôte du daemon Docker :
Ligne 1384: Ligne 2063:
  
 <code> <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> </code>
  
Ligne 1397: Ligne 2076:
 <code> <code>
 root@manager:~# cat extfile.cnf  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 extendedKeyUsage = serverAuth
 </code> </code>
Ligne 1411: Ligne 2090:
 </code> </code>
  
-====8.3 - 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 : Créez ensuite la clef privée **key.pem** du client qui se connectera au daemon à partir du réseau :
Ligne 1423: Ligne 2102:
 </code> </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> <code>
Ligne 1429: Ligne 2108:
 root@manager:~# cat /etc/hosts root@manager:~# cat /etc/hosts
 127.0.0.1 localhost 127.0.0.1 localhost
-127.0.1.1 manager.i2tch.loc manager +10.0.2.60 debian9.i2tch.loc debian9 
-10.0.2.15 manager.i2tch.loc manager +10.0.2.61 myregistry.i2tch.loc    myregistry 
-10.0.2.4 worker1.i2tch.loc worker1 +10.0.2.62 manager.i2tch.loc manager 
-10.0.2.5 worker2.i2tch.loc worker2  +10.0.2.63 worker1.i2tch.loc worker1 
-10.0.2.9 client.i2tch.loc client+10.0.2.64 worker2.i2tch.loc worker2
  
 # The following lines are desirable for IPv6 capable hosts # The following lines are desirable for IPv6 capable hosts
Ligne 1444: Ligne 2123:
  
 <code> <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> </code>
  
Ligne 1458: 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 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 Signature ok
-subject=CN = client.i2tch.loc+subject=CN = myregistry.i2tch.loc
 Getting CA Private Key Getting CA Private Key
 Enter pass phrase for ca-key.pem:fenestros Enter pass phrase for ca-key.pem:fenestros
Ligne 1522: Ligne 2201:
 </code> </code>
  
-====8.4 - 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 : Arrêtez et désactivez le service Docker :
Ligne 1585: Ligne 2264:
 </code> </code>
  
-====8.5 - 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_1** :+Transférez ensuite le certificat du CA ainsi que le certificat et la clef privée du client vers la VM **debian91** :
  
 <code> <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. ECDSA key fingerprint is SHA256:sEfHBv9azmK60cjqF/aJgUc9jg56slNaZQdAUcvBOvE.
 Are you sure you want to continue connecting (yes/no)? yes 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     ca.pem                                                                                                                                 100% 2163   917.8KB/s   00:00    
 key.pem                                                                                                                                100% 3243     3.0MB/s   00:00    key.pem                                                                                                                                100% 3243     3.0MB/s   00:00   
Ligne 1601: Ligne 2280:
 </code> </code>
  
-Vérifiez que le fichier **/etc/hosts** contient des entrées pour **client.i2tch.loc** et **manager.i2tch.loc** :+Lancez la commande **docker version** sur la VM **debian91** :
  
 <code> <code>
-trainee@client:~$ hostname +trainee@myregistry:~$ docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=manager.i2tch.loc:2376 version
-client.i2tch.loc +
-trainee@client:~$ su - +
-Mot de passe : fenestros +
-root@client:~# vi /etc/hosts +
-root@cleint:~# cat /etc/hosts +
-127.0.0.1 localhost +
-127.0.1.1 client.i2tch.loc client  +
-10.0.2.9 client.i2tch.loc client +
-10.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> +
- +
-<WRAP center round important 60%> +
-**Important** - Installez Docker-CE dans la machine virtuelle **Debian_9_1**. +
-</WRAP> +
- +
-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 Client: Docker Engine - Community
  Version:           19.03.4  Version:           19.03.4
Ligne 1658: Ligne 2313:
 </code> </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> <code>
-trainee@client:~$ mkdir -pv ~/.docker+trainee@myregistry:~$ mkdir -pv ~/.docker
 mkdir: création du répertoire '/home/trainee/.docker' mkdir: création du répertoire '/home/trainee/.docker'
 </code> </code>
Ligne 1668: Ligne 2323:
  
 <code> <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' 'ca.pem' -> '/home/trainee/.docker/ca.pem'
 'cert.pem' -> '/home/trainee/.docker/cert.pem' 'cert.pem' -> '/home/trainee/.docker/cert.pem'
Ligne 1677: Ligne 2332:
  
 <code> <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> </code>
  
Ligne 1683: Ligne 2338:
  
 <code> <code>
-trainee@client:~$ docker image ls+trainee@myregistry:~$ docker image ls
 REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
 i2tch/docker        nottrusted          686e85ee76b8        19 hours ago        5.03MB i2tch/docker        nottrusted          686e85ee76b8        19 hours ago        5.03MB
Ligne 1697: Ligne 2352:
  
 ----- -----
-<html> + 
-<div align="center"> +Copyright © 2022 Hugh Norris.
-Copyright © 2020 Hugh NORRIS +
-</div> +
-</html>+

Piste : • 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 • RH12401 - Système de Fichiers • LCF208 - Gestion de la Journalisation • RH12412 - Gestion des Services et des Démons • LRF406 - Système de Fichiers

Menu