CSAN

Les conteneurs

Les conteneurs sont, depuis quelques années, devenus une nouvelle manière de distribuer des logiciels. L'intérêt est la facilité avec laquelle il est possible de produire un environnement logiciel complexe puis le réutiliser ailleurs.

De nombreuses critiques fondées sont apparues sur cette nouvelle méthode de distribution. En effet, le nombre de vulnérabilités sont multipliées par tout ce qui est inclus dans les nombreuses strates du conteneur, contrairement à un package classique. Par ailleurs, l'environnement de construction et d'exécution du conteneur sont une autre source de vulnérabilité. La surface d'attaque est donc bien plus élevée.

Cela étant dit, les conteneurs offrent de nombreuses manières d'embarquer de l'information, notamment par un environnement riche en métadonnées. De plus, de nouveaux mécanismes et manières d'exécuter les conteneurs sont progressivement apparus, avec par exemple la possibilité d'éviter d'utiliser un démon lors de l'exécution ou bien en évitant toute exécution sous root. Des « capabilities » et les « cgroups » se sont progressivement enrichis, offrant un panel de possibilités pour contrer toute escalade de privilèges.

L'utilisation des conteneurs en environnement scientifique

L'ESR dispose de nombreuses ressources de calcul, répartis dans plusieurs centres nationaux et régionaux, dans des laboratoires, ou bien encore au travers de grilles et de cloud. L'idée d'utiliser les conteneurs dans cet environnement très hétérogène a fait son chemin, de part leur portabilité, mais la plupart des grands centres restent frileux quant à l'utilisation des conteneurs.

Le 1^er^ constat ci-dessus fait évidemment partie des craintes, mais ces derniers doivent également s'assurer que l'exécution se déroulera d'une part de manière logique et produira des résultats cohérents et d'autre part, de manière optimisée pour les ressources présentes ; que ça soit pour des cartes graphiques particulières ou des mécanismes d'accélération matériels autres (cartes FPGA, InfiniBand) et les mécanismes d'interactions logiciel associés (drivers, Cuda, MPI...).

La compatibilité de la couche logiciel du conteneur (versions et options de MPI, Cuda...) avec le noyau et les pilotes chargés par l'hôte est souvent un point délicat.

Émergence d'une idée de contrôle accrue et de partage d'expérience

Dans la chaîne de distribution des conteneurs, un point central concerne le « hub », en l'occurrence, le docker-hub¹, maintenu par la société docker. Sur cette plateforme de distribution, n'importe qui peut envoyer une image et la proposer à l'ensemble de la communauté. Quelqu'un de suffisamment expérimenté préfèrera toujours choisir une image dite « certifiée » qui offre plus de garantie car souvent construite avec soin par un acteur important. Sur un autre hub, « quay.io »², propriété de la société RedHat, un scan des images est régulièrement effectué, permettant de chercher des vulnérabilités (CVE) dans des bases de données, et un rapport permet de voir quels sont les risques d'utiliser l'image scannée. Côté calcul, un « singularity-hub »³ existe, reposant sur la technologie de conteneurs Singularity, mais ce dernier n'est guère maintenu et ne repose sur les épaules que d'une seule personne. En version Entreprise, SingularityPro⁴ propose une librairie avec des images signées et parfois réalisées par l'équipe même de Singularity et de partager ses propres images.

Le projet européen BioContainers⁵, porté par Elixir⁶ est déjà une avancée significative puisqu'il propose des conteneurs Singularity, docker et tout un environnement logiciel (souvent avec conda⁷), à toute la communauté biologie européenne, comportant un catalogue de métadonnées obligatoires, le tout intégré à un environnement logiciel assez large (forge logicielle, tests et intégration continue, intégration à des workflows, etc.)⁸.

Tous ces modèles ont chacun leur faiblesse : ils sont centralisés (peuvent donc être la source d'attaque type DDoS), ne proposent pas tous les mêmes fonctionnalités, avec des niveaux de sécurité plus ou moins forts, et pour des périmètres d'utilisation différents.

Du côté de l'intégration avec des ressources de calcul, l'Institut Français de Bioinformatique (IFB⁹) a poussé la réflexion un peu plus loin, puisqu'ils permettent de pousser directement vers les ressources de calcul du code validé sur un dépôt, éventuellement sous forme de conteneur¹⁰. D'autres structures (laboratoires, mésocentres, ...) proposent aussi, à leur niveau, des aides à la construction¹¹, au déploiement ou l'utilisation de conteneurs sur leurs ressources ¹², ¹³, ¹⁴.

Le modèle de distribution de Perl, R, TeX

Des modèles de distributions plus sécurisés et mieux contrôlés existent. C'est le cas par exemple des dépôts apt pour la distribution debian ou encore des Comprehensive Archive Network, tels que le CPAN¹⁵ (pour le langage de programmation Perl) ou le CRAN¹⁶ (langage R) ou encore le CTAN (TeX)¹⁷. De nombreux « miroirs » permettent de s'assurer que la ressource à télécharger est toujours disponible et d'y accéder rapidement par la proximité de ces derniers.

Dans le cas du CRAN, un processus soigné permet de s'assurer que le package est compatible avec des packages enfants, mais aussi parents (dépendances et dépendances inverses), lorsque celui-ci est publié, mais aussi lors des fréquentes mises à jour du langage, ou bien de l'archiver¹⁸.

Le projet CSAN

Ainsi a émergé l'idée du CSAN (Comprehensive Software Archive Network) : reproduire le même schéma que pour la distribution de packages R ou Perl, mais pour les conteneurs, en y apportant des métadonnées et des fonctionnalités utiles telles que des connexions à des dépôts de codes, permettant plus rapidement la publication de l'image et de manière automatisée.

Les métadonnées peuvent ainsi permettre aux centres de calcul d'indiquer si le conteneur tourne correctement chez eux, avec quelles versions et options de librairie et si ces derniers valident son utilisation sur leur centre.

Un projet gitlab est présent ici https://gitlab.in2p3.fr/csan , incluant un wiki¹⁹ et associé à un PoC :

https://apccsan.in2p3.fr

L'outil Harbor²⁰ a été utilisé (suivant le même modèle que le CERN²¹). Ce dernier est un projet de la CNCF²². Il permet de connecter plusieurs registres d'images, de répliquer l'image sur un autre registre, d'accéder de manière authentifiée au travers d'un annuaire LDAP, de définir des accès basés sur les rôles (RBAC), de scanner et signer les images, de rajouter les étiquettes (labels), des quotas, d'y accéder par une API restful, de déclencher des actions par webhooks²³...

Ainsi, il est possible pour un centre de calcul ou toute personne de confiance, de partager ses images de conteneurs avec les labels désirés, pour indiquer par exemple une compatibilité avec un type d'architecture matériel et logiciel, tout en publiant sur son propre registre sécurisé. Le registre étant ensuite relié à Harbor, permettant ainsi un partage et une capitalisation des pratiques.

Par ailleurs, l'outil Harbor étant décentralisé, il est possible de faire communiquer plusieurs Harbor, permettant un maillage bien plus large et une résilience plus forte de l'architecture²⁴.

1. https://hub.docker.com/ ↩

2. https://quay.io/ ↩

3. https://singularityhub.github.io/ ↩

4. https://sylabs.io/singularity-enterprise/ ↩

5. https://biocontainers.pro/ ↩

6. https://elixir-europe.org/ ↩

7. https://conda.io ↩

8. https://biocontainers-edu.readthedocs.io/en/latest/what\_is\_biocontainers.html ↩

9. https://www.france-bioinformatique.fr/ ↩

10. https://gitlab.com/ifb-elixirfr/cluster/tools ↩

11. https://web.mbb.cnrs.fr/wicopa/ ↩

12. https://deploymenthpc.sciencesconf.org/data/pages/slides\_Fede.pdf ↩

13. https://gricad-doc.univ-grenoble-alpes.fr/hpc/softenv/container/ ↩

14. https://www.calmip.univ-toulouse.fr/spip.php?article728 ↩

15. https://www.cpan.org/ ↩

16. https://cran.r-project.org/ ↩

17. https://ctan.org/ ↩

18. HORNIK, Kurt. The comprehensive R archive network. Wiley interdisciplinary reviews: Computational statistics, 2012, vol. 4, no 4, p. 394-398. ↩

19. https://gitlab.in2p3.fr/csan/csan/-/wikis/home ↩

20. https://goharbor.io/ ↩

21. https://indico.cern.ch/event/995485/contributions/4258063/ ↩

22. https://cncf.io/ ↩

23. https://fr.wikipedia.org/wiki/Webhook ↩

24. https://github.com/goharbor/harbor/wiki/Architecture-Overview-of-Harbor ↩