google/gvisorMet en bac à sable les conteneurs via un noyau applicatif en espace utilisateur qui intercepte les appels système, limite l'accès au noyau hôte et s'intègre à Docker/Kubernetes via un runtime OCI.
gVisor fournit une solide couche d'isolation entre les applications en cours d'exécution et le système d'exploitation hôte. C'est un noyau applicatif qui implémente une [interface de type Linux][linux]. Contrairement à Linux, il est écrit dans un langage sûr vis-à-vis de la mémoire (Go) et s'exécute dans l'espace utilisateur.
gVisor inclut un runtime [Open Container Initiative (OCI)][oci] appelé runsc
qui facilite l'utilisation des outils de conteneurs existants. Le runtime runsc
s'intègre à Docker et Kubernetes, ce qui simplifie l'exécution de conteneurs
en bac à sable.
seccomp-bpf), ni un wrapper au-dessus
des primitives d'isolation de Linux (par exemple firejail, AppArmor, etc.).gVisor adopte une troisième approche distincte, offrant de nombreux avantages de sécurité des VM tout en conservant une empreinte de ressources plus faible, un démarrage rapide et la flexibilité des applications ordinaires de l'espace utilisateur.
Les conteneurs ne sont pas un [bac à sable][sandbox]. Bien que les conteneurs aient révolutionné notre façon de développer, d'empaqueter et de déployer des applications, les utiliser pour exécuter du code non fiable ou potentiellement malveillant sans isolation supplémentaire n'est pas une bonne idée. Bien que l'utilisation d'un noyau unique et partagé permette des gains d'efficacité et de performance, cela signifie aussi qu'une évasion de conteneur est possible avec une seule vulnérabilité.
gVisor est un noyau applicatif pour les conteneurs. Il limite la surface du noyau hôte accessible à l'application tout en donnant à l'application accès à toutes les fonctionnalités qu'elle attend. Contrairement à la plupart des noyaux, gVisor ne suppose ni n'exige un ensemble fixe de ressources physiques ; il tire plutôt parti des fonctionnalités existantes du noyau hôte et s'exécute comme un processus normal. En d'autres termes, gVisor implémente Linux au moyen de Linux.
gVisor ne doit pas être confondu avec les technologies et outils visant à durcir les conteneurs contre les menaces externes, à fournir des contrôles d'intégrité supplémentaires ou à limiter la portée d'accès d'un service. Il faut toujours être prudent quant aux données rendues disponibles à un conteneur.
La documentation utilisateur et l'architecture technique, y compris les guides de démarrage rapide, sont consultables sur [gvisor.dev][gvisor-dev].
gVisor se compile sur x86_64 et ARM64. D'autres architectures pourront devenir disponibles à l'avenir.
Pour les besoins de ces instructions, [bazel][bazel] et les autres dépendances de compilation
sont encapsulés dans un conteneur de compilation. Il est possible d'utiliser
[bazel][bazel] directement, ou de taper make help pour les cibles standard.
Assurez-vous que les dépendances suivantes sont installées :
Compilez une archive de version contenant runsc, le shim containerd containerd-shim-runsc-v1,
et quelques binaires annexes que runsc s'attend à trouver dans un
répertoire gvisor-bin/ à côté de lui-même, puis extrayez-la vers /usr/local/bin :
make release-tarball DESTINATION=bin/
sudo tar -C /usr/local/bin -xf bin/gvisor.tar.bz2
Pour compiler des bibliothèques ou des binaires spécifiques, vous pouvez spécifier la cible :
make build TARGETS="//pkg/tcpip:tcpip"
L'utilisation directe de Bazel n'est pas recommandée en raison de la surcharge supplémentaire, mais pour commencer :
Après avoir configuré les dépendances, l'utilisation de Bazel est similaire à celle du Makefile :
bazel build -c opt //debian:gvisor-release-tar-bz2
Pour exécuter les suites de tests standard, vous pouvez utiliser :
make unit-tests
make tests
Pour exécuter des tests spécifiques, vous pouvez spécifier la cible :
# Makefile
make test TARGETS="//runsc:version_test"
# Bazel
bazel test //runsc:version_test
Certains paquets prennent en charge l'exécution des tests directement sur macOS. Au moment de la rédaction de ce document, gVisor nécessite bazel 8, que vous pouvez installer via homebrew :
brew install bazel@8
# You can then run the tests, e.g.:
$(brew --prefix bazel@8)/bin/bazel test --macos_sdk_version=$(xcrun --show-sdk-version) -- //tools/nogo/... //tools/check{aligned,const,escape,linkname,locks,unsafe}/...
go getCe projet utilise [bazel][bazel] pour construire et gérer les dépendances. Une branche go synthétique est maintenue pour être compatible avec les outils go standards, par commodité. Cela est utile pour les paquets et bibliothèques externes qui dépendent des sous-paquets gVisor (par exemple, le réseau en espace utilisateur via Netstack) afin d'importer du code Go gVisor dans leurs projets Go.
Sélectionnez cette branche explicitement avec la requête de branche go. @latest résout vers master, ce qui nécessite Bazel et n'est pas compatible avec les outils Go standards :
go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go
REMARQUE : les builds de runsc à partir de cette branche ne sont pas pris en charge. gVisor et
runsc nécessitent plusieurs binaires (dont certains ne sont même pas écrits en Go) pour
fonctionner. La branche go est prise en charge au mieux, et
le développement direct sur cette branche n'est pas pris en charge. Le développement doit avoir lieu sur
la branche master, qui est ensuite répercutée dans la branche go.
Consultez GOVERNANCE.md pour les informations relatives à la gouvernance du projet.
Consultez ADOPTERS.md pour une liste des utilisateurs et adopteurs connus en production.
La [liste de diffusion gvisor-users][gvisor-users-list] et la [liste de diffusion gvisor-dev][gvisor-dev-list] sont de bons points de départ pour les questions et les discussions.
Consultez SECURITY.md.
Consultez Releases.
Consultez Contributing.md.