Hébergement et noms de domaine

Nous avons récemment reçu un mail de la DSI [1] nous informant que cette dernière propose maintenant un hébergement gratuit des sites web professionnels. Auparavant, ce service était payant.

L’apparition de ce nouvel hébergeur potentiel a lancé une discussion sur l’hébergement du blog sur Apache Spark que Christian Arnault est actuellement en train de monter à l’adresse spark.in2p3.fr.

Christian a considéré deux hébergeurs privés, WordPress.com et Overblog.  Il s’est cependant rapidement heurté aux limitations des fonctionnalités proposées gratuitement par ces derniers. Ainsi, WordPress demandait un paiement pour l’attribution d’un nom de domaine en rapport avec Spark, et Overblog inondait trop les visiteurs de publicités pour un blog professionnel.

Il a aussi pensé à héberger ce blog au LAL. Cependant, ce dernier mettait un trop fort accent sur l’utilisation d’un nom de domaine en .lal.in2p3.fr, dont le périmètre institutionnel restreint déplaisait à Christian du fait de la vocation universaliste de son blog. Serge a clarifié que le problème résidait dans la gestion trop fastidieuse des nombreux noms de domaines extérieurs, qui demandent une maintenance manuelle régulière.

Sur ce sujet des noms de domaines, Christian a mentionné plus tard par mail que le CNRS peut aussi fournir un service de noms de domaine plus général (notamment en .cnrs.fr, et en .fr via RENATER). Michel a cependant rappelé qu’il est nécessaire que les demandes de noms de domaines passent par le groupe exploitation, afin que ce dernier garde une visibilité sur les domaines gérés par le LAL.

Christian s’est ensuite tourné vers le CCIN2P3 [2]. Ce dernier lui a fourni un nom de domaine un peu plus générique en in2p3.fr, mais en revanche ne fournissait pas d’assistance particulière à l’installation et la configuration de sites. Christian a donc dû installer et configurer son installation de WordPress lui-même avec l’aide de Serge et Justine.

Une question qui reste encore à régler est celle des permissions d’édition. Pour l’instant, les gens doivent se créer un compte sur le blog Spark, et demander «manuellement» la permission d’écrire des articles à Christian. Idéalement, Christian souhaiterait que cette permission soit offerte automatiquement à quiconque s’inscrit à la mailing-list Spark, mais cela requiert une intégration entre la gestion de comptes de Sympa [3] et WordPress qui est actuellement perçue comme trop complexe pour en valoir la peine.

ElasticSearch et Kibana

Philippe s’est rendu à l’atelier sur ElasticSearch et Kibana aux JDEV. Il a trouvé ces outils intéressants pour des utilisations de «déboguage des données», par exemple pour chercher des corrélations statistiques ou des anomalies dans ces dernières.

Une application particulière qu’il avait en tête était l’analyse de logs. Il a été remarqué qu’analyser des logs n’est pas une pratique nouvelle, et qu’on l’avait évoqué lors d’une réunion Dev@Lal il y a un an et demi. Il a été aussi remarqué que ce ne sont pas les seuls outils disponibles pour ce travail, par exemple Spark est aussi parfois utilisé pour analyser des logs de serveurs afin de détecter des pannes. Il existe d’ailleurs une passerelle permettant à Spark de manipuler des données via ElasticSearch.

Le sujet de Spark étant invoqué, la discussion a un peu dérivé sur la capacité de MongoDB à gérer des données temporelles comme des logs. En effet, SQL n’est pas très simple à utiliser pour ce type de travail, mais la dimension «temps» est très utile quand on cherche à étudier des anomalies de latence. Christian a expliqué que ce n’est pas une information native en MongoDB non plus, mais qu’on peut éventuellement la gérer au niveau de la couche Spark supérieure.

Dans l’écosystème ElasticSearch, un outil de visualisation qui peut être utilisé pour ce type est Logstash, qui a également été présenté aux JDEV.

Certains des outils liés (X-Pack, lié à ElasticSearch) sont distribués sous un modèle commercial «freemium», avec une version gratuite disposant de fonctionnalités limitées et une version payante donnant accès au jeu complet de fonctionnalités. Quand on utilise ce type d’outil, il est important d’étudier attentivement les limites de la version gratuite et les conditions de licence de la version payante. Il n’est pas rare, par exemple, que la version gratuite soit open source, mais la version payante soit propriétaire.

Christian a mentionné qu’ElasticSearch serait plutôt efficace pour des besoins de recherche multicritère dans des documents texte, et qu’il était utilisé dans ce but par Nuxeo, le moteur d’Atrium. Il est aussi utilisé pour le moteur de recherche Qwant.

Quelqu’un a aussi mentionné que Dominique Mège du CCIN2P3 avait pas mal d’expérience de la mise en place de ce type d’outils d’analyse statistique.

Conteneurs et machines virtuelles

Qu’est-ce qu’un conteneur?

Antoine, David, Hadrien, Michel et Philippe ont suivi l’atelier sur Docker, LXD et Singularity aux JDEV, présenté par Alexandre Dehne Garcia et Martin Souchal. Cela été l’occasion de clarifier un peu la situation de l’écosystème des conteneurs, qui peut être difficile à aborder.

Pour comprendre la notion de conteneur, un bon point de départ est de considérer leurs prédécesseurs spirituels, les machines virtuelles. Pourquoi utilise-t-on généralement des machines virtuelles?

• Pour s’abstraire du matériel et du système d’exploitation «hyperviseur» sous-jacent et exécuter une application basée sur le matériel virtuel et le système d’exploitation de son choix.
• Pour contrôler l’accès de l’application au système d’une façon plus fine que le système d’exploitation sous-jacent ne le permet (par exemple,  dissimuler l’existence de certains matériels).
• Pour exécuter l’application dans une configuration matérielle et système bien contrôlée afin de maximiser les chances qu’elle se comporte comme dans l’environnement où elle a été développée.

Mais a-t-on vraiment besoin de toute la complexité d’une machine virtuelle pour atteindre ces objectifs? Il se trouve que sous Linux, ce n’est pas toujours le cas:

• On a rarement besoin de simuler du matériel qui n’existe pas sur l’hôte (et on souhaite rarement le faire, car c’est très inefficace)
• Il est devenu possible «au niveau système» de dissimuler une partie du système hôte, y compris les processus en cours d’exécution et les périphériques d’entrée-sortie disponibles, avec de nouvelles fonctionnalités du noyau Linux comme les cgroups [4].
• Le noyau Linux évolue assez lentement de nos jours, donc on a rarement des problèmes de compatibilité avec le noyau du système d’exploitation hôte. Les problèmes de compatibilité apparaissent plutôt au niveau de l’environnement applicatif (compilateur, versions des bibliothèques partagées…).
• Par diverses astuces impliquant le système de fichiers virtuel, on peut aisément «greffer» l’environnement applicatif d’un système Linux sur le noyau d’un autre.

L’idée d’un conteneur est donc de dire que lorsqu’on veut exécuter une application Linux sur un hôte Linux, on peut se permettre d’éliminer la complexité d’une émulation/isolation matérielle et d’une duplication du noyau de système d’exploitation hôte, et à la place ne dupliquer que l’environnement applicatif de l’application cible en l’installant par-dessus le noyau du système hôte. C’est ce que fait Docker sous Linux.

Depuis quelques années, Docker est aussi disponible sous Windows et OSX. Mais sous ces systèmes, il ne peut bien entendu fonctionner comme sous Linux, puisqu’il ne dispose pas d’un noyau Linux sous-jacent. Les versions de Docker disponibles sous OSX et Windows ne sont donc en réalité qu’une machine virtuelle Linux sous le capot. Historiquement, cette machine virtuelle était basée sur VirtualBox, mais depuis 2016, Docker peut aussi utiliser les fonctionnalités de virtualisations natives d’OSX et Windows quand on utilise une version de ces systèmes d’exploitation qui propose de telles fonctionnalités.

Docker est par exemple utilisé pour répondre aux besoins de reproductibilité logicielle d’environnements d’intégration continue, ainsi que dans les enseignements du master NPAC. Mais ce logiciel a certaines limitations en termes de sécurité qui freinent son développement dans d’autres domaines, notamment en production sur la grille de calcul ou dans des supercalculateurs…

L’écosystème des conteneurs

Docker a popularisé la notion de conteneur, mais il ne l’a pas inventée et n’en est pas la seule incarnation. Un grand nombre d’alternatives existent, chacune attaquant le problème sous un angle un peu différent.

Ainsi, une critique de Docker qui est souvent formulée par les administrateurs système est que son isolation est très poreuse. Une application s’exécutant au sein d’un conteneur Docker peut très facilement obtenir un accès administrateur au système hôte, et par ce biais avoir accès à des ressources système dont le conteneur est censé l’isoler. Par conséquent, l’isolation fournie par Docker n’est pas suffisante dans des scénarios où on doit exécuter du code auquel on n’accorde pas une confiance totale, comme c’est le cas par exemple lorsque la grille du CERN exécute des programmes d’analyse écrits par des physiciens sans compétence particulière en sécurité informatique. C’est ainsi qu’on se retrouve dans des situations assez absurdes, comme Amazon faisant tourner des conteneurs Docker par-dessus leur infrastructure de machines virtuelles.

Une solution possible à ce problème est Singularity, un système développé pour le milieu des supercalculateurs qui propose une solution de conteneur dans laquelle l’application s’exécute comme processus ordinaire et n’a pas d’accès administrateur au système hôte. Un effort a été fait pour que l’utilisation de Singularity soit similaire à celle de docker (les Dockerfiles étant compatibles), à ceci près bien sûr que l’utilisateur n’a plus le droit d’utiliser des commandes administratives comme «sudo» dans le conteneur. Cette solution semble donc bien adaptée à la conteneurisation d’applications individuelles nécessitant peu de privilèges système et auxquelles on n’accorde qu’une confiance limitée, ce qui devrait bien correspondre aux besoins de l’informatique scientifique.

Pour ceux qui auraient besoin d’exécuter des applications plus complexes nécessitant un accès plus poussé au système, et ne pouvant donc se satisfaire d’un conteneur limité à l’exécution d’applications non privilégiées, un projet peut être plus intéressant est l’extension de l’infrastructure LXC (LinuX Containers), historiquement utilisée par Docker et CoreOS, via une nouvelle surcouche appelée LXD. Contrairement à Docker, cette plate-forme se destine plutôt à la virtualisation de systèmes complets que d’applications isolées. Entre autres choses, elle vise à offrir de meilleures performances quand on lance de grands nombres de conteneurs, proposer une gestion fine des privilèges système accordés aux conteneurs, et permettre de migrer plus facilement des conteneurs d’un système à l’autre. Elle est donc à première vue mieux pensée pour des déploiements de conteneurs complexes, en production et à grande échelle.

Au-delà des conteneurs actuels

Si les technologies de conteneurs disponibles aujourd’hui sont plus légères et éliminent pas mal de complexité quand on les compare à des machines virtuelles, elles sont cependant encore loin d’atteindre l’efficacité du gestionnaire de paquet natif d’une distribution Linux moderne. Le trafic réseau important engendré par la nécessité de recopier l’équivalent de l’environnement applicatif complet d’un système d’exploitation est notamment un problème, qui limite l’application de ces technologies dans des contextes où la bande passante est limitée, par exemple lorsqu’on organise des TPs basés sur des conteneurs dans des locaux dont la connexion réseau n’est pas dernier cri.

En principe, Docker pourrait répondre à ce problème, car il permet d’ajouter des changements incrémentaux à une image existante et de ne transférer que ces changements si le client possède déjà une copie de l’image de base. Mais en pratique, l’absence de standardisation des images «mères» et la jeunesse de la technologie font que cette possibilité est difficile à exploiter en pratique.

En réponse à ce problème, diverses solutions ont été proposées. Une approche particulièrement prometteuse est d’adapter le concept de gestionnaire de paquet pour lui permettre de mieux répondre aux besoins de reproductibilité logicielle, via un contrôle plus fin des dépendances. Cette approche est poursuivie par les gestionnaires de paquets Nix et Spack, le premier se voulant plus généraliste et le second plus orienté vers les besoins du calcul haute performance.

Antoine a précisé par la suite que le tutoriel Nix présenté aux JDEV est en ligne à l’adresse https://gricad.github.io/calcul/nix/tuto/2017/07/04/nix-tutorial.html, et qu’il est possible de le rejouer en environ 3h.

Une autre évolution, matérielle celle-ci, qui a le potentiel de changer beaucoup l’utilisation qu’on a des conteneurs est Intel SGX (Software Guard eXtensions). C’est une technologie qui vise à permettre aux applications de créer des régions mémoires protégées, inaccessibles au système d’exploitation sous-jacent. L’isolation est assurée en ne conservant les données en clair qu’au niveau du CPU, en limitant drastiquement l’accès à ces données au sein du CPU, et en chiffrant toute donnée destinée à être stockée en RAM.

En principe, cela devrait permettre par exemple de sécuriser les applications de type «cloud» où l’on fait tourner du code sur des serveurs sur lesquels on n’a aucun contrôle et qui sont potentiellement sujets à espionner ce qui se passe. Ce propos optimiste doit toutefois être nuancé en mentionnant ce système possède aussi plusieurs caractéristiques nettement plus discutables:

• Pour déployer une application SGX en production (c’est-à-dire supprimer l’accès aux régions mémoires protégées offert à d’autres applications pendant la phase de débogage), il faut obtenir une licence d’Intel, représentée logiciellement par une signature cryptographique dont l’autorité de certification racine est Intel. Selon le brevet américain 8 972 746 d’Intel, c’est une décision de conception volontaire, visant à permettre l’émergence de nouveaux modèles commerciaux («is an enforcement point for a number of new business models»). Le brevet évoque ensuite de façon répétée le potentiel lucratif de la chose pour Intel.
• Comme il est également expliqué dans ce brevet, une application ainsi authentifiée par Intel peut, si Intel lui en donne la permission, aussi avoir accès à des secrets cryptographiques stockés au sein du processeur, tels que la clé «Enhanced Privacy ID» (EPID). Cette clé de chiffrement, écrite en dur dans chaque processeur et donc non révocable, est au coeur de la sécurité de SGX, et une telle application possède donc la capacité de briser la sécurité de SGX (et potentiellement celle d’autres technologies hardware de sécurité des processeurs x86).
• De nombreux aspects de l’implémentation de SGX qui jouent un rôle essentiel pour sa sécurité ne sont pas documentés par Intel. Comme Costan et Devadas l’expliquent dans leur analyse de SGX publiée en 2016, cela empêche une analyse extérieure complète de la sécurité de ce système. C’est problématique, car cela signifie que seuls les ingénieurs d’Intel sont en mesure de dire précisément quelles sont les limites de la sécurité du système SGX, or il n’est pas dans leur intérêt commercial de le faire.
• SGX est, dans sa conception même, vulnérable à de nombreuses attaques de type «side-channel» accessibles à d’autres logiciels tournant sur le même système hôte. Ainsi, une attaque par minutage de cache permettant d’accéder en 5 minutes à 96% des 4096 bits d’une clé cryptographique RSA censée être protégée par SGX a été publiée cette année. Comble de l’ironie, le logiciel attaquant utilisait également SGX pour dissimuler son activité malveillante du système d’exploitation hôte.
• Comme toute extension x86, SGX ne restera pas éternellement spécifique au milieu des gros datacenters, mais finira à terme par atterrir dans des processeurs grand public. Sur ces derniers, il est à craindre que sa principale application ne soit l’implémentation de systèmes de type DRM, visant à donner aux géants du multimédia un contrôle total et centralisé sur les oeuvres qu’ils distribuent. Cette utilisation a été explicitement prévue par Intel, comme ils l’expliquent dans le brevet susmentionné en mentionnant comme cas d’utilisation un lecteur de vidéos. Or, la généralisation de DRMs protégés au niveau matériel a des implications inquiétantes en termes d’interopérabilité des logiciels libres, de censure politique des contenus numériques, et de pérennité des oeuvres artistiques.

Glossaire

1. Direction des Systèmes d’Information du CNRS, qui gère les services informatiques centralisés comme Agate et Janus.
2. Centre de calcul de l’IN2P3.
3. Sympa est un système de gestion de mailing lists très utilisé dans la communauté de l’enseignement supérieur en France.
4. Les cgroups sont une fonctionnalité du noyau Linux permettant de manipuler des groupes de processus en leur imposant des restrictions communes, par exemple un budget total de RAM ou la (non-)visibilité des interfaces réseau.