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 à gestion mémoire sûre (Go) et s'exécute en 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 réduite, un démarrage rapide et la flexibilité des applications en espace utilisateur classiques.
Les conteneurs ne sont pas un [bac à sable][sandbox]. Bien que les conteneurs aient révolutionné notre façon de développer, packager et 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 pas et ne requiert pas un ensemble fixe de ressources physiques ; à la place, il exploite les 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 disponibles 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 release contenant runsc, le shim containerd containerd-shim-runsc-v1,
et quelques binaires sidecar 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 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 au 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 de 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 compiler et gérer les dépendances. Une branche
go synthétique est maintenue, compatible avec l'outillage go standard pour
plus de 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) pour importer le code Go de gVisor
dans leurs projets Go.
Sélectionnez cette branche explicitement avec la requête de branche go. @latest résout
master, qui nécessite Bazel et n'est pas compatible avec l'outillage Go standard :
go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go
REMARQUE : les compilations de runsc depuis cette branche ne sont pas prises 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 reflétée dans la branche go.
Voir GOVERNANCE.md pour les informations de gouvernance du projet.
Voir 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.
Voir SECURITY.md.
Voir Contributing.md.