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 [2021/04/14 10:31] adminelearning:workbooks:docker2:drf03 [2021/12/29 10:32] (Version actuelle) admin
Ligne 1: Ligne 1:
 +
 ~~PDF:LANDSCAPE~~ ~~PDF:LANDSCAPE~~
  
-Version : **2021.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
-    * Présentation des Namespaces +    * LAB #1 - Travailler avec les CGroups 
-    * Présentation des CGroups +      1.1 - Présentation des Namespaces 
-      * LAB #1 - Travailler avec les CGroups +      * 1.2 Présentation des CGroups 
-        * 1.- Limitation de la Mémoire +      * 1.- Limitation de la Mémoire 
-        * 1.- Le Paquet cgroup-tools +      * 1.- Le Paquet cgroup-tools 
-          * La commande cgcreate +        * La commande cgcreate 
-          * La Commande cgexec +        * La Commande cgexec 
-          * La Commande cgdelete +        * La Commande cgdelete 
-          * Le Fichier /etc/cgconfig.conf +        * Le Fichier /etc/cgconfig.conf 
-    * LAB #2 - Création d'un Utilisateur de Confiance pour Contrôler le Daemon Docker +    * LAB #2 - Utilisation des Docker Secrets 
-    * LAB #- Le Script docker-bench-security.sh +    * LAB #3 - Création d'un Utilisateur de Confiance pour Contrôler le Daemon Docker 
-    * LAB #- Sécurisation de la Configuration de l'Hôte Docker +    * LAB #- Le Script docker-bench-security.sh 
-      * 4.1 - [WARN] 1.2.1 - Ensure a separate partition for containers has been created +    * LAB #- Sécurisation de la Configuration de l'Hôte Docker 
-      * 4.2 - [WARN] 1.2.3 - Ensure auditing is configured for the Docker daemon +      * 5.1 - [WARN] 1.2.1 - Ensure a separate partition for containers has been created 
-    * LAB #- Sécurisation de la Configuration du daemon Docker +      * 5.2 - [WARN] 1.2.3 - Ensure auditing is configured for the Docker daemon 
-      * 5.1 - [WARN] 2.1 - Ensure network traffic is restricted between containers on the default bridge +    * LAB #- Sécurisation de la Configuration du daemon Docker 
-      * 5.2 - [WARN] 2.8 - Enable user namespace support +      * 6.1 - [WARN] 2.1 - Ensure network traffic is restricted between containers on the default bridge 
-      * 5.3 - [WARN] 2.11 - Ensure that authorization for Docker client commands is enabled +      * 6.2 - [WARN] 2.8 - Enable user namespace support 
-      * 5.4 - [WARN] 2.12 - Ensure centralized and remote logging is configured +      * 6.3 - [WARN] 2.11 - Ensure that authorization for Docker client commands is enabled 
-      * 5.5 - [WARN] 2.14 - Ensure Userland Proxy is Disabled +      * 6.4 - [WARN] 2.12 - Ensure centralized and remote logging is configured 
-      * 5.6 - [WARN] 2.17 - Ensure containers are restricted from acquiring new privileges +      * 6.5 - [WARN] 2.14 - Ensure Userland Proxy is Disabled 
-      * 5.7 - Le Fichier /etc/docker/daemon.json +      * 6.6 - [WARN] 2.17 - Ensure containers are restricted from acquiring new privileges 
-    * LAB #- Sécurisation des Images et les Fichiers de Construction +      * 6.7 - Le Fichier /etc/docker/daemon.json 
-      * 6.1 - [WARN] 4.1 - Ensure a user for the container has been created +    * LAB #- Sécurisation des Images et les Fichiers de Construction 
-      * 6.2 - [WARN] 4.5 - Ensure Content trust for Docker is Enabled +      * 7.1 - [WARN] 4.1 - Ensure a user for the container has been created 
-      * 6.3 - [WARN] 4.6 - Ensure that HEALTHCHECK instructions have been added to container images +      * 7.2 - [WARN] 4.5 - Ensure Content trust for Docker is Enabled 
-    * LAB #- Sécurisation du Container Runtime +      * 7.3 - [WARN] 4.6 - Ensure that HEALTHCHECK instructions have been added to container images 
-      * 7.1 - [WARN] 5.1 - Ensure AppArmor Profile is Enabled +    * LAB #- Sécurisation du Container Runtime 
-      * 7.2 - [WARN] 5.2 - Ensure SELinux security options are set, if applicable +      * 8.1 - [WARN] 5.1 - Ensure AppArmor Profile is Enabled 
-      * 7.3 - [WARN] 5.10 - Ensure memory usage for container is limited +      * 8.2 - [WARN] 5.2 - Ensure SELinux security options are set, if applicable 
-      * 7.4 - [WARN] 5.11 - Ensure CPU priority is set appropriately on the container +      * 8.3 - [WARN] 5.10 - Ensure memory usage for container is limited 
-      * 7.5 - [WARN] 5.12 - Ensure the container's root filesystem is mounted as read only +      * 8.4 - [WARN] 5.11 - Ensure CPU priority is set appropriately on the container 
-      * 7.6 - [WARN] 5.14 - Ensure 'on-failure' container restart policy is set to '5' +      * 8.5 - [WARN] 5.12 - Ensure the container's root filesystem is mounted as read only 
-      * 7.7 - [WARN] 5.25 - Ensure the container is restricted from acquiring additional privileges +      * 8.6 - [WARN] 5.14 - Ensure 'on-failure' container restart policy is set to '5' 
-      * 7.8 - [WARN] 5.26 - Ensure container health is checked at runtime +      * 8.7 - [WARN] 5.25 - Ensure the container is restricted from acquiring additional privileges 
-      * 7.9 - [WARN] 5.28 - Ensure PIDs cgroup limit is used +      * 8.8 - [WARN] 5.26 - Ensure container health is checked at runtime 
-    * LAB #- Sécurisation des Images avec Docker Content Trust +      * 8.9 - [WARN] 5.28 - Ensure PIDs cgroup limit is used 
-      * 8.1 - DOCKER_CONTENT_TRUST +    * LAB #- Sécurisation des Images avec Docker Content Trust 
-      * 8.2 - DCT et la commande docker pull+      * 9.1 - DOCKER_CONTENT_TRUST 
 +      * 9.2 - DCT et la commande docker pull
         * L'option disable-content-trust         * L'option disable-content-trust
-      * 8.3 - DCT et la commande docker push +      * 9.3 - DCT et la commande docker push 
-      * 8.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 #- Sécurisation du Socket du Daemon Docker +    * LAB #10 - Sécurisation du Socket du Daemon Docker 
-      * 9.1 - Création du Certificat de l'Autorité de Certification +      * 10.1 - Création du Certificat de l'Autorité de Certification 
-      * 9.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 
-      * 9.3 - Création du Certificat du Client +      * 10.3 - Création du Certificat du Client 
-      * 9.4 - Démarrage du Daemon Docker avec une Invocation Directe +      * 10.4 - Démarrage du Daemon Docker avec une Invocation Directe 
-      * 9.5 - Configuration du Client+      * 10.5 - Configuration du Client
  
 +=====LAB #1 - Travailler avec les CGroups======
  
-=====Présentation des Namespaces=====+====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. 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.
  
-=====Présentation des CGroups=====+====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 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.
Ligne 201: Ligne 204:
 </WRAP> </WRAP>
  
-====LAB #1 - Travailler avec les CGroups==== +====1.- Limitation de la Mémoire====
- +
-===1.- Limitation de la Mémoire===+
  
 Pour travailler avec les CGroups dans Debian 9, il convient d'installer les outils nécessaires : Pour travailler avec les CGroups dans Debian 9, il convient d'installer les outils nécessaires :
Ligne 348: Ligne 349:
 </WRAP> </WRAP>
  
-===1.- Le Paquet cgroup-tools===+====1.- Le Paquet cgroup-tools====
  
 Le paquet **cgroup-tools** installe des commandes dites //de facilité// dont : Le paquet **cgroup-tools** installe des commandes dites //de facilité// dont :
  
-==La commande cgcreate==+===La commande cgcreate===
  
 Cette commande permet la création d'un CGroup : Cette commande permet la création d'un CGroup :
Ligne 395: Ligne 396:
 </code> </code>
  
-==La Commande cgexec==+===La Commande cgexec===
  
 Cette commande permet d'insérer la limitation dans le CGroup **et** de lancer le script en une seule ligne : Cette commande permet d'insérer la limitation dans le CGroup **et** de lancer le script en une seule ligne :
Ligne 407: Ligne 408:
 </code> </code>
  
-== La Commande cgdelete==+=== La Commande cgdelete===
  
 Une fois le script terminé, cette commande permet de supprimer le cgroup : Une fois le script terminé, cette commande permet de supprimer le cgroup :
Ligne 424: Ligne 425:
 </code> </code>
  
-==Le Fichier /etc/cgconfig.conf==+===Le Fichier /etc/cgconfig.conf===
  
 Afin de les rendre persistants, il convient de créer les CGroups dans le fichier **/etc/cgconfig.conf** : Afin de les rendre persistants, il convient de créer les CGroups dans le fichier **/etc/cgconfig.conf** :
Ligne 512: Ligne 513:
 </code> </code>
  
-=====LAB #2 - Création d'un Utilisateur de Confiance pour Contrôler le Daemon Docker=====+=====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 #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 537: Ligne 753:
 </code> </code>
  
-=====LAB #- Le Script docker-bench-security.sh=====+=====LAB #- 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 605: Ligne 821:
   * **[NOTE]** : Vous informe d'un **best practice**.   * **[NOTE]** : Vous informe d'un **best practice**.
  
-=====LAB #- Sécurisation de la Configuration de l'Hôte Docker=====+=====LAB #- 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 641: 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]**.
  
-====4.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é.
  
-====4.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 745: Ligne 961:
 </code> </code>
  
-=====LAB #- Sécurisation de la Configuration du daemon Docker=====+=====LAB #- 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 776: 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]**.
  
-====5.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 782: 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]]**.
  
-====5.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 788: 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]]**.
  
-====5.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 794: 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]]**.
  
-====5.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 800: 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]]**.
  
-====5.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 811: 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]]**.
  
-====5.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 817: 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]]**.
  
-====5.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 870: 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 #- Sécurisation des Images et les Fichiers de Construction=====+=====LAB #- Sécurisation des Images et les Fichiers de Construction=====
  
 Créez le conteneur mysql : Créez le conteneur mysql :
Ligne 922: Ligne 1138:
 </code> </code>
  
-====6.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]]**.
  
-====6.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 976: 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]]**.
  
-====6.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 990: 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 #- Sécurisation du Container Runtime=====+=====LAB #- 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 1045: 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]**.
  
-====7.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 1051: 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]]**.
  
-====7.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 1057: 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]]**.
  
-====7.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 1090: 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]]**.
  
-====7.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 1098: 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]]**.
  
-====7.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 1167: Ligne 1383:
 </WRAP> </WRAP>
  
-====7.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 1175: 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]]**.
  
-====7.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 1183: 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]]**.
  
-====7.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.
  
-====7.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 1289: Ligne 1505:
 </code> </code>
  
-=====LAB #- Sécurisation des Images avec Docker Content Trust=====+=====LAB #- 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 1299: 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]]**.
  
-====8.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 1316: Ligne 1532:
 </code> </code>
  
-====8.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 1423: Ligne 1639:
 </code> </code>
  
-====8.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é :
Ligne 1507: Ligne 1723:
 </code> </code>
  
-====8.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 1767: Ligne 1983:
 </code> </code>
  
-=====LAB #- 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 1785: Ligne 2005:
 </code> </code>
  
-====9.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 1820: Ligne 2040:
 </code> </code>
  
-====9.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 1870: Ligne 2090:
 </code> </code>
  
-====9.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 1981: Ligne 2201:
 </code> </code>
  
-====9.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 2044: Ligne 2264:
 </code> </code>
  
-====9.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 **debian91** : Transférez ensuite le certificat du CA ainsi que le certificat et la clef privée du client vers la VM **debian91** :
Ligne 2060: Ligne 2280:
 </code> </code>
  
-Lancez la commande **docker version** sur la VM **docker91** :+Lancez la commande **docker version** sur la VM **debian91** :
  
 <code> <code>
Ligne 2132: Ligne 2352:
  
 ----- -----
-<html> + 
-<div align="center"> +Copyright © 2022 Hugh Norris.
-Copyright © 2021 Hugh NORRIS +
-</div> +
-</html>+
Menu