Kata Containers ou l’étonnant rapprochement entre OpenStack et AWS

Des containers sécurisés qui bénéficient surtout à AWS, contre Google

« Kata Containers est bon exemple de projet qui incarne nos principes d’ouverture. Quatorze entreprises contribuent à son code, dont certaines qui n’adhèrent pas à la fondation », a ainsi lancé sur scène la développeuse Andrea Florescu qui avait planché sur une préversion du projet du temps où elle travaillait chez Intel. Renseignement pris, il s’avère qu’elle non plus ne fait pas partie de la fondation, puisque sa page LinkedIn indique qu’elle est désormais salariée chez AWS, en charge du nouvel hyperviseur Firecracker.

Selon la description officielle, Kata Containers est censé exécuter des containers mieux isolés les uns des autres en les encapsulant dans des machines virtuelles légères. Interrogé sur le type d’applications qui pourraient tourner dans des containers de ce type, Thierry Carrez, le responsable de l’ingénierie au sein de la fondation OpenStack, répond de manière un peu vague que le cible principale sont toutes les applications qui fonctionnent en cloud public. Or, à date, Kata Containers, ayant besoin d’un hyperviseur et le seul compatible en cloud public étant Firecracker, ce système fonctionnera en définitive surtout sur EC2, l’offre IaaS d’AWS.

« Autrefois, quand notre ambition était de proposer une plateforme d’infrastructure cloud complète et open source, notre ennemi était AWS. Ce n’est plus le cas, car d’une part AWS a mis Firecracker en open source et, d’autre part, nous ne visons plus qu’à proposer des modules autonomes d’infrastructure. AWS est donc devenu un partenaire et nous collaborons pour que notre Kata Containers fonctionne avec leur Firecracker », poursuit Thierry Carrez.

Pour bien comprendre le fonctionnement de Kata Containers avec Firecracker, Thierry Carrez présente au MagIT un schéma fonctionnel qui oppose la technologie commune à gVisor, l’hyperviseur que Google utilise dans Cloud Engine, son offre d’IaaS public. GVisor était jusqu’ici le seul logiciel à savoir exécuter des containers de manière sécurisée. En somme, si la fondation doit casser une hégémonie, et même si elle ne cite personne en particulier, sa seule cible possible est ici Google, le concurrent direct d’AWS.

Google n’est manifestement pas dupe. Selon un organigramme que LeMagIT a pu consulter, il a mandaté un développeur pour participer aux prochaines mises à jour de Kata Containers, un certain Jon Olson.  

Le risque est ici que les infrastructures Kata Containers déployées en cloud privé ne soient transposables que sur le cloud public d’AWS, dans le cas d’un projet de cloud hybride. AWS avait précédemment pris un certain avantage sur ses concurrents en étant le premier à bénéficier d’une migration directe des VMs au format VMware sur son IaaS EC2.

Plus un simulateur de Docker qu’un véritable runtime de containers

Kata Containers, contrairement à ce que son nom indique, n’est pas à proprement parler une technologie de containerisation. Le logiciel consiste à placer, en sandwich entre un hyperviseur et ses machines virtuelles, une couche qui fait croire à un contrôleur Kubernetes que les VMs du dessus sont des containers Docker. L’enjeu d’Intel et Hyper.sh, les deux entreprises qui ont à la base conçu ce principe, est de mettre en production des VMs aussi facilement que des containers : avec les outils automatiques de Kubernetes, plutôt qu’avec des scripts longs comme le bras à écrire à la main. La fondation OpenStack n’a pas de scrupule à admettre que Kubernetes est meilleur que ses outils pour piloter des clusters de containers, puisque Kubernetes est lui-même lancé et configuré par le module Magnum de la fondation.

L’intérêt d’utiliser des VMs plutôt que des containers est d’éviter un risque bien précis de cybersécurité : un pirate qui aurait empoisonné le code d’une application dans un container avec un exploit de type Spectre/Meltdown pourrait dérober les données d’un autre container en passant par le noyau de leur OS commun. Rappelons en effet que les containers utilisent tous l’OS du serveur hôte, tandis que les machines virtuelles ont chacune le leur. On comprend au passage pourquoi Intel, dont les processeurs sont principalement concernés par ce type d’attaques, est à l’initiative de Kata Containers.

A la clé, il y a l’enjeu pour les hébergeurs de cloud de garantir à leurs clients qu’ils ne seront pas contaminés par les applications infectées d’une autre entreprise.

Kata Container a vocation à exécuter un container, voire un POD, par VM. Un POD est un ensemble de containers prévus pour fonctionner ensemble ; par exemple une application et son serveur de base de données.

La couche installée entre l’hyperviseur et les VMs est Kata-Runtime. Autrefois appelé RunV, ce bout de logiciel imite le comportement de RunC, l’ordonnanceur de Docker. Kata-Runtime reçoit les ordres d’administration de Kubernetes de la même façon que le fait RunC. En revanche, il ne se charge pas d’ordonnancer les instances virtuelles et repose sur les fonctions de l’hyperviseur pour le faire, d’où la nécessité absolue que ce dernier soit présent. Docker, lui, peut fonctionner depuis un serveur dépourvu de virtualisation.

La technologie Kata Containers prévoit par ailleurs d’installer un agent dans chaque machine virtuelle. Cet agent communique avec la couche Kata-Runtime pour configurer l’application de sa VM avec les paramètres envoyés par Kubernetes (nom sur le réseau, nom du système de fichiers accessible, adresses des autres containers sur le réseau qui contiennent les données, etc.), exactement comme le fait RunC avec ses containers.

La performance tient à l’utilisation de Firecracker, plutôt qu’à des VM soi-disant légères

Le problème des VMs en revanche est qu’elles mettent d’ordinaire une à dix secondes à se lancer, tandis qu’un container démarre en une centaine de millisecondes. Diverses techniques ont donc été prévues pour que les machines virtuelles démarrent en moyenne en 500 millisecondes quand elles sont utilisées avec Kata Containers. Pour commencer, via l’agent, Kata-Runtime peut partager des ressources situées au niveau de l’OS du serveur hôte, celui qui porte l’hyperviseur, et d’autres hébergées dans des containers tiers. En théorie, ce système devrait permettre de n’installer dans chaque VM qu’un OS réduit aux fonctions minimales, voire avec un noyau taillé sur mesure.

« Dans les machines virtuelles, on place un système qui sait tout faire. L’idée ici est de mettre un OS qui ne sert qu’à lancer le processus que l’on aurait mis dans un container », précise Thierry Carrez. Sauf qu’on se doute que les DSI n’ont pas attendu Kata Containers pour optimiser leurs VMs. Les améliorations possibles à ce niveau restent donc à démontrer.

Une autre technique consiste à alléger l’hyperviseur.
OpenStack utilise d’ordinaire un hyperviseur en deux parties. La première, KVM, est située dans le noyau. Elle sert à découper la puissance processeur et la RAM disponible en autant de segments qu’il doit y avoir de machines virtuelles. Seul logiciel capable de gérer le plus haut niveau d’interruption du processeur - le « ring 0 » - KVM passe la main aux instances virtuelles à tour de rôle et selon leur priorité, comme un OS fait du multitâche.

La seconde partie de l’hyperviseur est QEMU. Ce logiciel a été initialement conçu pour émuler du x86 sur les processeurs Power d’IBM et vice-versa. Sur des serveurs x86 exécutant des VM x86, il ne sert en revanche qu’à virtualiser les périphériques : le stockage en mode bloc, en mode fichier, le réseau, voire les ports USB, la console d’affichage, etc. C’est ici qu’entre en scène Firecracker d’AWS : il constitue une alternative à QEMU débarrassée de la couche d’émulation, ce qui permettrait de démarrer l’hyperviseur lui-même en seulement 125 millisecondes. Accessoirement, Firecracker ne pèse que 5 Mo, soit 3 à 4 fois moins que QEMU.

Il est à noter que Kata Containers fonctionne aussi par-dessus QEMU. En revanche, dans ce mode, son intérêt est discutable par rapport à un véritable runtime Docker installé dans une machine virtuelle – ce que font jusqu’ici tous les fournisseurs de cloud, publics comme privés, pour garantir une meilleure sécurité à leurs clients.

Demain, des pilotes Virtio pour paralléliser les entrées-sorties

Publié en version 1.6 à l’occasion de l’Open Infrastructure Summit, Kata Containers supporte désormais les processeurs ARM, tout comme le fait Firecracker. La feuille de route des deux logiciels prévoit qu’ils exploitent de plus en plus les pilotes Virtio de KVM. Ces pilotes sont spécifiquement écrits pour découper en tranches parallèles tous les flux d’entrée-sortie (stockage, réseau, bus PCIe, horloge, etc.) du noyau Linux, afin de mieux router les communications entre les machines virtuelles. Le premier contrôleur disponible doit être Virtio-fs, le pilote qui partage les accès à un volume de fichiers.

Afin de motiver les développements autour de l’API Virtio, la fondation a mis en chantier le projet Rust-VMM. Celui-ci correspond à un kit de développement en langage Rust pour écrire des canaux de communication ou des contrôleurs virtuels. Les développements issus de Rust-VMM devraient permettre de proposer des versions customisées de Firecracker pour certains types d’application.

Reste à savoir si ces versions customisées seront utilisables ailleurs que sur AWS : si Amazon autorise bien les entreprises à déployer son hyperviseur sur leurs clouds privés, sa licence Open source interdit à quiconque d’en modifier le code.