diff --git a/images/csan.png b/images/csan.png new file mode 100644 index 0000000000000000000000000000000000000000..9050d2ccb5c42b8d445c06ab052d45b0957b13e0 Binary files /dev/null and b/images/csan.png differ diff --git a/images/logo-calcul.png b/images/logo-calcul.png new file mode 100644 index 0000000000000000000000000000000000000000..bfe3d514e6d279d44ea54e023314599dbe8976e8 Binary files /dev/null and b/images/logo-calcul.png differ diff --git a/images/oci.png b/images/oci.png new file mode 100644 index 0000000000000000000000000000000000000000..40f959fa981cdaa1a6d5973c42d3c8497aaeae5f Binary files /dev/null and b/images/oci.png differ diff --git a/images/seccomp.png b/images/seccomp.png new file mode 100644 index 0000000000000000000000000000000000000000..443bb2cbb28bb3d3230391cdd77a617fa92f3b22 Binary files /dev/null and b/images/seccomp.png differ diff --git a/images/slurm.jpg b/images/slurm.jpg new file mode 100644 index 0000000000000000000000000000000000000000..d93c35a29ac064f10764c00c4c3a0f6ea6e33d41 Binary files /dev/null and b/images/slurm.jpg differ diff --git a/images/software-supply-chain.png b/images/software-supply-chain.png new file mode 100644 index 0000000000000000000000000000000000000000..8eae6d22b073d04e897c88331f7c15fd0a70d0e6 Binary files /dev/null and b/images/software-supply-chain.png differ diff --git a/images/vm-container.png b/images/vm-container.png new file mode 100644 index 0000000000000000000000000000000000000000..4c39aaa29ad0dc6d1c15da8521347a49bcb68bf0 Binary files /dev/null and b/images/vm-container.png differ diff --git a/prez.html b/prez.html index fdd0789c10546b7e8c72090c69b046659f211ee1..a892a3560df80472bc7c34ab19e655b7a42ada70 100644 --- a/prez.html +++ b/prez.html @@ -23,8 +23,9 @@ # Conteneurs pour le calcul - # ![](images/singu.png) - # ![](images/licence.png) + + + ###### Martin Souchal 2021 (APC - FACe - ComputeOps) @@ -85,6 +86,8 @@ alias docker=singularity ... ``` + + --- # Vocabulaire @@ -94,7 +97,7 @@ - Registre : un serveur abritant des images de conteneurs - Repository : ensemble de registres - + .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 + + - 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 + + + + - 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) + + + .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é) + + --- # 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 @@
- 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/) - + --- # Nomad @@ -442,7 +530,7 @@ --- - # 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 + + --- # Conclusion ---