Skip to content

GitLab

Commit 7193ac72 authored by Martin Souchal's avatar Martin Souchal
Browse files
Options

Conclusion

parent 22617782
Pipeline #99696 passed with stages
      in 1 minute and 23 seconds
      Hide whitespace changes
      Inline Side-by-side
      Showing with 117 additions and 24 deletions
      prez.html
      View file @ 7193ac72
      ......@@ -23,8 +23,9 @@
      # Conteneurs pour le calcul
      # ![](images/singu.png)
      # ![](images/licence.png)
      <img style="width:100px;" src="images/logo-calcul.png" >
      <img style="width:100px;" src="images/logo-computeops-web.png" >
      <img style="width:100px;" src="images/licence.png" >
      ###### Martin Souchal 2021 (APC - FACe - ComputeOps)
      ......@@ -85,6 +86,8 @@
      alias docker=singularity
      ...
      ```
      <img style="float:right;" src="images/oci.png" >
      ---
      # Vocabulaire
      ......@@ -94,7 +97,7 @@
      - Registre : un serveur abritant des images de conteneurs
      - Repository : ensemble de registres
      <img style="width:60%;" src="images/Containers-scheme.png" >
      <img style="width:60%;float: right;" src="images/Containers-scheme.png" >
      .footnote[Source : Manage Docker containers, by Bachir Chihani and Rafael Benevides]
      ---
      ......@@ -103,6 +106,8 @@
      - Plusieurs formats de manifestes : Dockerfile, Singularity...
      - Un manifeste est transformé en image via un mécanisme de build (intégré ou non)
      - Un conteneur peut être construit "from scratch" ou a partir d'une autre image
      - La base d'une image est un OS Linux (Alpine Linux, Busybox, Ubuntu, CentOs...)
      - Pas de standards pour les manifestes
      ```yaml
      FROM python:3
      ......@@ -114,7 +119,13 @@
      COPY . /code/
      ```
      ```bash
      docker build Dockerfile
      docker build -f Dockerfile -t Container .
      ```
      ```bash
      singularity build Container.sif Singularity.def
      ```
      ```bash
      buildah bud -f Dockerfile -t Container .
      ```
      ---
      # Runtimes
      ......@@ -131,6 +142,8 @@
      ---
      # Isolation et performances
      <img style="width:45%;float: right;" src="images/vm-container.png" >
      - runtimes de bas niveau en user mode (namespaces) :
      - Temps d'instanciation minimal
      - Isolation faible (proche du matériel)
      ......@@ -144,19 +157,68 @@
      - Performances lièes aux formats d'images
      - Format en couches optimisés pour téléchargement
      - Format fchier optimisé pour le stockage
      .footnote[Source : Three Easy Ways to Improve a Container’s Performance by Marialena Perpiraki]
      ---
      # Isolation et Sécurité
      ### focus sur seccomp
      - Seccomp est utilisé par Docker et Singularity
      - Permet de filtrer les syscalls depuis les runtimes (liste noire/blanche)
      ```bash
      ~ $ docker info
      ...
      Security Options:
      apparmor
      seccomp
      Profile: default # default seccomp profile applied by default
      ...
      ```
      - En désactivant completement seccomp, tous les syscalls sont autorisés :
      ```bash
      # Lancer un conteneur sans seccomp
      ~ $ docker run --rm -it --security-opt seccomp=unconfined alpine sh
      / # reboot # oops
      # Lancer docker avec le profil seccomp par défaut
      ~ $ docker container run --rm -it alpine sh
      / # reboot # ouf
      ```
      ---
      # Isolation et Sécurité
      ### focus sur seccomp
      <img style="float: right;" src="images/seccomp.png" >
      - Lancement d'un conteneur avec un profil seccomp personnalisé
      ```bash
      # Run avec un profil interdisant le chmod
      ~ $ docker container run --rm -it --security-opt seccomp=no-chmod.json alpine sh
      / # whoami
      root
      / # chmod 777 -R /etc
      chmod: /etc: Operation not permitted
      ```
      .footnote[Source : [ITNext](https://itnext.io/hardening-docker-and-kubernetes-with-seccomp-a88b1b4e2111)]
      ---
      # Sécurité
      - Docker : daemon root, possibilité d'être root dans un conteneur
      - Possibilité d'utiliser AppArmor ou seccomp coté admin pour "verrouiller" l'infra
      - Conteneurs user mode :
      - même utilisateur hors du conteneur et dans le conteneur
      - les problématiques de sécurité sont reportées sur le noyau linux
      - Isolation plus ou moins forte
      - Vecteur de failles de sécurité logicelle important
      - les problématiques d'élévation de priviléges sont reportées sur le noyau linux
      - Attention au SUID...
      - Isolation plus ou moins forte (de userNS a VM)
      - Vecteur de failles de sécurité logicelle important (cf Alpine Linux)
      - Vecteur d'attaque pour rootkit (très facile de cacher du code malicieux dans un conteneur)
      <img style="float: right;" src="images/software-supply-chain.png" >
      .footnote[SetUID : un programme lancé avec le droit “suid” sera exécuté avec les droits du propriétaire du programme et non les droits de l'utilisateur qui l'a lancé]
      ---
      # Registres publics
      ### Ou trouver des images de conteneurs prêtes à l'emploi ?
      * Images vérifées
      - [NVIDIA NGC](https://ngc.nvidia.com) - images orientées GPU
      ......@@ -167,9 +229,10 @@
      - [Singularity Hub](https://singularity-hub.org/)
      - [Sylabs cloud](https://cloud.sylabs.io/) - images signées
      - [Quay.io](https://quay.io/) (scan de sécurité)
      <img style="width:200px;float: right;" src="images/csan.png" >
      ---
      # Registres privés
      ### Comment partager ses applications conteneurisées ?
      - Gitlab (Registre Docker)
      - Harbor (Registre Docker)
      ......@@ -269,9 +332,11 @@
      - Aucun support MPI.
      - Image docker : superpositions de couches, pas très portable dans un cluster
      - GPU Nvidia supportés par [nvidia-docker](https://github.com/NVIDIA/nvidia-docker)
      - Utilisé massivement en Intégration continue
      - Sécurité :
      - daemon root à installer sur tous les noeuds de calculs...
      - des utilisateurs root dans votre cluster...
      - mais sécurisation possible via seccomp
      .right[![](images/docker-filesystems-multilayer.png)]
      ---
      ......@@ -291,12 +356,13 @@
      <hr />
      Nom | Dernière Release | Support | OCI
      ------------- | ------------- | ------------- | -------------
      [Charlie-cloud](https://github.com/hpc/charliecloud) | 18/12/2020 | MPI - GPU - IB | Non
      [Singularity](https://github.com/hpcng/singularity) | 12/01/2021 | MPI - GPU - IB | Oui
      [Shifter](https://github.com/NERSC/shifter) | 01/04/2018 | MPI - GPU - IB | Non
      [Nvidia enroot](https://github.com/NVIDIA/enroot) | 02/12/2020 | GPU - IB | Oui
      Nom | Dernière Release | Support HW | OCI | ARM | OS | Compatible Scheduler | Contrôle Admin | Priviléges
      ------------- | ------------- | ------------- | ------------- | -------------| -------------| -------------| -------------| -------------
      Docker | 04/01/2021 | GPU Nvidia | Oui | Oui | MacOs - W$ - Linux | Non | Oui | Root daemon
      [Charlie-cloud](https://github.com/hpc/charliecloud) | 18/12/2020 | MPI - IB | Non | Non | Linux | Oui | Non | UserNS
      [Singularity](https://github.com/hpcng/singularity) | 12/01/2021 | MPI - GPU - IB | Oui | Oui | Linux - MacOs | Oui | Oui | SUID/UserNS
      [Shifter](https://github.com/NERSC/shifter) | 01/04/2018 | MPI - GPU - IB | Non | Non | Linux | Non | Oui | SUID
      [Nvidia enroot](https://github.com/NVIDIA/enroot) | 02/12/2020 | GPU - IB | Oui | Non | Linux | Oui | Non | UserNS
      ---
      background-image: url(images/charlie.png)
      ......@@ -330,6 +396,29 @@
      - Ecrit en C
      - Libre et gratuit
      ---
      # Nvidia enroot
      *Enroot peut être considéré comme un chroot non privilégié amélioré. Il utilise les mêmes technologies sous-jacentes que les conteneurs mais supprime une grande partie de l'isolement qu'ils procurent tout en préservant la séparation du système de fichiers.*
      - Pratique le principe KISS
      - Standalone (pas de daemon)
      - Tourne en namespace user (pas de binaire setuid, cgroup, configuration par utilisateur...)
      - Facile à utiliser (simple image format, scriptable, root remapping...)
      - Pas à peu d'isolation
      - Configuration administrateur et utilisateur
      - Import rapide d'images Docker (vitesse de 3x à 5x sur des grosses images)
      - Images SquashFS
      - Support GPU Nividia avec libnvidia-container
      - Packages DEB et RPM, make install...
      ```bash
      # Import and start an Ubuntu image from DockerHub
      $ enroot import docker://ubuntu
      $ enroot create ubuntu.sqsh
      $ enroot start ubuntu
      ```
      ---
      name: inverse
      class: center, inverse, middle
      ......@@ -339,7 +428,7 @@
      background-image: url(images/singu.png)
      # Historique
      * Inventé par Greg Kurtzer (CentOS, Warewulf) au Berkeley Lab pour répondre aux problèmes spécifiques au HPC
      * Inventé par Greg Kurtzer (Rocky Linux, CentOS, Warewulf) au Berkeley Lab pour répondre aux problèmes spécifiques au HPC
      * Développement démarré en Octobre 2015
      * Première release en Avril 2016
      * Les retours de la communauté ont menés à la version 2.0 en Juin 2016
      ......@@ -354,7 +443,6 @@
      * Necessite Golang > 1.13 pour la compilation
      * Package RPM uniquement
      * Droits root nécessaires pour créer un conteneur localement
      * SIF est le format d'image par défaut, apportant chiffrement, signature et vérification
      * Fichier image unique, executable
      * Infrastructure Cloud (Container Library, Remote Builder, et Keystore)
      * Possibilité d’exécuter des images Docker et OCI
      ......@@ -372,7 +460,7 @@
      * Les utilisateurs peuvent passer un contexte d’exécution SELinux, ou un profil AppArmor
      * Les utilisateurs peuvent passer leurs propres filtres d’appel système via seccomp
      * Support d’exécution avec des UID/GID différents pour l’utilisateur root
      * Conteneurs chiffrés (SIF)
      * Conteneurs chiffrés, signés (SIF)
      ---
      background-image: url(images/singu.png)
      ......@@ -381,9 +469,9 @@
      - Facile à installer et à déployer sur un cluster de calcul
      - Compatibilité avec Docker
      - Utilisation de registres Public/Privé dédiés (http://www.singularity-hub.org/)
      - Un conteneur est facile à transporter pour l'utilisateur (un fichier à copier)
      - Un conteneur est facile à transporter pour l'utilisateur (un fichier SIF à copier)
      - Singularity apps
      - Compatible tous scheduler (Dans Singularity, pas de démon, vu comme une application standard par le Job Scheduler. Compatible avec les vieux noyaux, pas de problèmes de sécurité (ou rarement). Pas de ‘cgroups‘ ; les limites sont fixées par le Job Scheduler.)
      - Compatible tous scheduler
      - Intégration de tests et d'aide intégrée dans le conteneur
      - Accès direct aux GPU de la machine
      - Intégration dans Kubernetes
      ......@@ -413,7 +501,7 @@
      * Possibilité de lancer plusieurs pods en parallèle (mais pas avec MPI).
      * Singularity-CRI est fourni avec le support natif des GPU NVIDIA en [device plugin](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
      <img style="width:30%;float:right" src="images/kubernetes_icons.svg" >
      <img style="width:100px;float:right" src="images/kubernetes_icons.svg" >
      ---
      # Nomad
      ......@@ -442,7 +530,7 @@
      <img style="width:30%;float:right" src="images/nomad.svg" >
      ---
      # Désavantages de Nomad :
      # Désavantages de Nomad
      * Kubernetes fournit tous les services necessaires pour faire tourner des conteneurs Docker or Rkt-based (cluster management, scheduling, service discovery, monitoring, secrets management, ...).
      * Nomad est développé par une seule entité, HashiCorp et n'a pas de support communautaire.
      ......@@ -456,8 +544,13 @@
      # Job scheduler
      - Approche Job avec heure de début - fin, ressources à utiliser
      - mécanismes de files d’attente/de mises en attente ou pause (checkpointing), de priorités / Fair sharing, droits/accès et partages des ressources physiques.
      - mécanismes de
      - files d’attente/de mises en attente ou pause (checkpointing)
      - priorités / Fair sharing
      - droits/accès et partages des ressources physiques
      - Intégration dans l’environnement cluster existant
      <img style="width:30%;float:right" src="images/slurm.jpg" >
      ---
      # Conclusion
      ---
      ......
      Markdown is supported
      0% or .
      You are about to add 0 people to the discussion. Proceed with caution.
      Finish editing this message first!
      Please register or to comment