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 couche d'isolation robuste entre les applications en cours d'exécution et le système d'exploitation hôte. Il s'agit d'un noyau applicatif qui implémente une interface de type Linux. Contrairement à Linux, il est écrit dans un langage sûr en mémoire (Go) et s'exécute dans l'espace utilisateur.
gVisor inclut un runtime Open Container Initiative (OCI) appelé runsc
qui facilite l'utilisation des outils de conteneurisation existants. Le runtime runsc
s'intègre avec Docker et Kubernetes, ce qui simplifie l'exécution de conteneurs
sandboxés.
seccomp-bpf), ni une surcouche
des primitives d'isolation de Linux (p. ex. firejail, AppArmor, etc.).gVisor adopte une troisième approche distincte, offrant de nombreux avantages de sécurité des machines virtuelles tout en conservant l'empreinte en ressources plus faible, le démarrage rapide et la flexibilité des applications classiques en espace utilisateur.
Les conteneurs ne sont pas une sandbox. Bien que les conteneurs aient révolutionné la façon de développer, d'empaqueter et de déployer les applications, les utiliser pour exécuter du code non fiable ou potentiellement malveillant sans isolation supplémentaire n'est pas une bonne idée. Si l'utilisation d'un noyau unique et partagé permet des gains d'efficacité et de performance, elle signifie aussi qu'une seule vulnérabilité permet de s'échapper du conteneur.
gVisor est un noyau applicatif pour conteneurs. Il limite la surface du noyau hôte accessible à l'application tout en donnant à celle-ci 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 destinés à durcir les conteneurs contre les menaces externes, à fournir des contrôles d'intégrité supplémentaires ou à limiter le périmètre d'accès d'un service. Il faut toujours être prudent quant aux données mises à disposition d'un conteneur.
La documentation utilisateur et l'architecture technique, y compris les guides de démarrage rapide, sont disponibles sur gvisor.dev.
gVisor se compile sur x86_64 et ARM64. D'autres architectures pourraient être prises en charge à l'avenir.
Pour ces instructions, bazel et les autres dépendances de compilation sont
encapsulés dans un conteneur de compilation. Il est possible d'utiliser
bazel directement, ou de taper make help pour les cibles standard.
Assurez-vous que les dépendances suivantes sont installées :
Construisez une archive de release contenant runsc, le shim containerd
containerd-shim-runsc-v1 et quelques binaires auxiliaires 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
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 permettent d'exécuter les tests directement sur macOS. Au moment de la rédaction, 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 pour construire et gérer les dépendances. Une branche go
synthétique est maintenue pour être compatible avec l'outillage go standard, par commodité.
Cela est utile aux paquets et bibliothèques externes qui dépendent de sous-paquets gVisor
(par exemple, la mise en réseau en espace utilisateur via Netstack) pour importer le code Go de
gVisor dans leurs projets Go.
Sélectionnez explicitement cette branche avec la requête de branche go. @latest résout
master, qui nécessite Bazel et n'est pas compatible avec les outils Go standard :
go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go
REMARQUE : les compilations de runsc à partir de cette branche ne sont pas prises en charge.
Pour fonctionner, gVisor et runsc nécessitent plusieurs binaires (dont certains ne sont
même pas écrits en Go). 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 se faire 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.
La liste de diffusion gvisor-users et la liste de diffusion gvisor-dev sont de bons points de départ pour les questions et les discussions.
Voir SECURITY.md.
Voir Contributing.md.