gVisor : le noyau applicatif qui isole les conteneurs

Un noyau applicatif en espace utilisateur

gVisor se définit comme un noyau d'application pour conteneurs : une couche d'isolation forte entre les applications et le système hôte, qui implémente une interface de type Linux. Deux traits le distinguent d'un noyau classique : il est écrit en Go, un langage sûr pour la mémoire, et il tourne en espace utilisateur, comme un simple processus. Le projet revendique une voie intermédiaire : beaucoup des bénéfices de sécurité d'une VM, avec l'empreinte mémoire réduite, le démarrage rapide et la flexibilité d'une application ordinaire. Le dépôt, écrit en Go, affiche 19 181 étoiles, 1 946 forks et 839 issues ouvertes sous licence Apache 2.0.

Ni filtre de syscalls, ni machine virtuelle

Le README consacre une section entière à ce que gVisor n'est pas, signe d'une confusion fréquente. Ce n'est pas un filtre de syscalls comme seccomp-bpf, ni un habillage des primitives d'isolation Linux à la firejail ou AppArmor. Ce n'est pas non plus une VM au sens courant, à la VirtualBox ou QEMU. gVisor prend une troisième voie : implémenter l'interface Linux lui-même, dans un processus utilisateur, en s'appuyant sur les fonctions du noyau hôte sans supposer un ensemble fixe de ressources physiques. Le README résume la démarche par une formule : implémenter Linux au moyen de Linux. Cette clarification compte pour qui compare les solutions d'isolation, car le mécanisme, et donc le profil de risque, diffère.

runsc : le runtime OCI pour Docker et Kubernetes

L'entrée pratique du projet est runsc, un runtime conforme à l'Open Container Initiative. Il s'intercale dans l'outillage existant : le README vante son intégration avec Docker et Kubernetes, qui rend simple l'exécution de conteneurs isolés. Côté construction, la release tarball contient runsc, le shim containerd-shim-runsc-v1 et quelques binaires secondaires que runsc attend dans un dossier gvisor-bin voisin. Le raisonnement du projet est rappelé sans détour : les conteneurs ne sont pas un bac à sable, et un noyau partagé unique permet une évasion de conteneur avec une seule vulnérabilité. gVisor limite la surface de noyau accessible tout en offrant les fonctions attendues par l'application.

Compiler depuis les sources : Bazel, Make et Linux 5.6

Le build vise x86_64 et ARM64, les autres architectures restant à venir. Les prérequis sont explicites : Linux 5.6 ou plus et Docker 17.09.0 ou plus, Bazel étant enveloppé dans un conteneur de build. La voie normale passe par make : make release-tarball DESTINATION=bin/, puis extraction du gvisor.tar.bz2 dans /usr/local/bin. Des cibles ciblées existent, comme make build TARGETS=//pkg/tcpip:tcpip, et les suites de tests se lancent avec make unit-tests ou make tests. Utiliser Bazel directement est déconseillé pour sa surcharge, mais documenté : bazelisk ou la version du fichier .bazelversion, puis bazel build -c opt //debian:gvisor-release-tar. Sur macOS, certains paquets se testent avec bazel 8 installé via Homebrew.

La branche go pour importer Netstack et sous-paquets

Particularité notable pour les projets Go : gVisor se construit avec Bazel, et master n'est pas compatible avec l'outillage go standard. Le projet maintient donc une branche synthétique nommée go, interrogeable explicitement : go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go. Le README prévient que @latest résout master, ce qui échouera sans Bazel. Cette branche sert surtout aux projets externes qui veulent importer des sous-paquets, la pile réseau utilisateur Netstack et pkg/tcpip en tête. Ses limites sont écrites : les builds de runsc depuis cette branche ne sont pas pris en charge, le support est du meilleur effort et le développement doit rester sur master, répercuté ensuite vers go.

Des releases datées et une gouvernance écrite

Les versions suivent un calendrier : la release courante s'appelle release-20260817.0, publiée le 25 août 2026, un schéma de datation qui identifie immédiatement l'ancienneté d'un binaire déployé. La CI s'appuie sur un pipeline Buildkite, complété par un workflow CodeQL sur GitHub. La gouvernance est formalisée dans GOVERNANCE.md, et ADOPTERS.md liste les utilisateurs connus en production, une ressource à consulter pour juger de la maturité en conditions réelles. Les listes de diffusion gvisor-users et gvisor-dev servent de points d'entrée pour les questions et discussions. Cette transparence organisationnelle accompagne un projet technique dense, dont la documentation utilisateur et l'architecture technique vivent sur gvisor.dev.

Apache 2.0, politique de sécurité et contributions

Le code est sous licence Apache 2.0 : usage commercial, modification, redistribution et sous-licence autorisés, avec la concession de brevets caractéristique et l'absence de garantie. Le projet publie une politique de sécurité dédiée, SECURITY.md, canal approprié pour les signalements sensibles, plutôt que l'issue tracker public. Les contributions suivent CONTRIBUTING.md. Pour une équipe qui évalue gVisor, la démarche documentée consiste à lire l'architecture sur gvisor.dev, à vérifier ADOPTERS.md pour des usages comparables au sien, puis à tester runsc sur une charge réelle dans un environnement isolé, les guides de démarrage rapide restant sur gvisor.dev.

Conclusion éditoriale

gVisor vise ceux qui exécutent du code non fiable dans des conteneurs et veulent limiter la surface du noyau hôte sans payer le prix d'une VM complète. Le chemin d'installation documenté passe par make release-tarball puis l'extraction dans /usr/local/bin, avec Linux 5.6+, Docker 17.09.0+ et un build limité à x86_64 et ARM64. Intégré comme runtime runsc dans Docker ou Kubernetes, il change le compromis sécurité-performance ; les releases sont datées, la 20260817.0 publiée le 25 août 2026, ce qui impose d'épingler la version testée. Pour importer des sous-paquets Go comme Netstack, utilisez la branche go, pas @latest.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes