google/gvisorSandboxt Container über einen Userspace-Anwendungskernel, der Systemaufrufe abfängt, den Zugriff auf den Host-Kernel einschränkt und über eine OCI-Runtime in Docker/Kubernetes integriert.
gVisor bietet eine starke Isolationsschicht zwischen laufenden Anwendungen und dem Host-Betriebssystem. Es ist ein Anwendungskernel, der eine [Linux-ähnliche Schnittstelle][linux] implementiert. Anders als Linux ist er in einer speichersicheren Sprache (Go) geschrieben und läuft im Userspace.
gVisor enthält eine [Open Container Initiative (OCI)][oci]-Runtime namens runsc,
die die Arbeit mit bestehenden Container-Tools erleichtert. Die runsc-Runtime
integriert sich in Docker und Kubernetes und macht das Ausführen von sandboxed
Containern einfach.
seccomp-bpf) und auch kein Wrapper über
Linux-Isolationsprimitive (z. B. firejail, AppArmor usw.).gVisor verfolgt einen eigenständigen dritten Ansatz, der viele Sicherheitsvorteile von VMs bietet und gleichzeitig den geringeren Ressourcenverbrauch, den schnellen Start und die Flexibilität regulärer Userspace-Anwendungen beibehält.
Container sind keine [Sandbox][sandbox]. Während Container die Art und Weise revolutioniert haben, wie wir Anwendungen entwickeln, paketieren und bereitstellen, ist ihre Verwendung zum Ausführen nicht vertrauenswürdigen oder potenziell bösartigen Codes ohne zusätzliche Isolation keine gute Idee. Die Verwendung eines einzigen, gemeinsam genutzten Kernels ermöglicht zwar Effizienz- und Leistungsgewinne, bedeutet aber auch, dass ein Container-Escape mit einer einzigen Schwachstelle möglich ist.
gVisor ist ein Anwendungskernel für Container. Er begrenzt die für die Anwendung zugängliche Host-Kernel-Oberfläche und gibt der Anwendung dennoch Zugriff auf alle Funktionen, die sie erwartet. Anders als die meisten Kernel setzt gVisor keine feste Menge physischer Ressourcen voraus oder erfordert sie; stattdessen nutzt es vorhandene Host-Kernel-Funktionalität und läuft als normaler Prozess. Mit anderen Worten: gVisor implementiert Linux mittels Linux.
gVisor sollte nicht mit Technologien und Tools verwechselt werden, die Container gegen externe Bedrohungen härten, zusätzliche Integritätsprüfungen bereitstellen oder den Zugriffsbereich für einen Dienst einschränken. Man sollte stets sorgfältig darauf achten, welche Daten einem Container zur Verfügung gestellt werden.
Benutzerdokumentation und technische Architektur, einschließlich Schnellstartanleitungen, finden sich unter [gvisor.dev][gvisor-dev].
gVisor baut auf x86_64 und ARM64. Andere Architekturen könnten in Zukunft verfügbar werden.
Für die Zwecke dieser Anleitung sind [bazel][bazel] und andere Build-Abhängigkeiten
in einem Build-Container gebündelt. Es ist möglich, [bazel][bazel] direkt zu
verwenden oder make help für Standard-Targets einzugeben.
Stellen Sie sicher, dass die folgenden Abhängigkeiten installiert sind:
Bauen Sie ein Release-Tarball, das runsc, den containerd-shim-runsc-v1
containerd-Shim und einige Sidecar-Binaries enthält, die runsc in einem
gvisor-bin/-Verzeichnis neben sich erwartet, und entpacken Sie es nach
/usr/local/bin:
make release-tarball DESTINATION=bin/
sudo tar -C /usr/local/bin -xf bin/gvisor.tar.bz2
Um bestimmte Bibliotheken oder Binaries zu bauen, können Sie das Target angeben:
make build TARGETS="//pkg/tcpip:tcpip"
Die direkte Verwendung von Bazel wird aufgrund des zusätzlichen Overheads nicht empfohlen, aber um loszulegen:
Nach dem Einrichten der Abhängigkeiten ist die Verwendung von Bazel ähnlich wie mit dem Makefile:
bazel build -c opt //debian:gvisor-release-tar-bz2
Um Standard-Testsuiten auszuführen, können Sie Folgendes verwenden:
make unit-tests
make tests
Um bestimmte Tests auszuführen, können Sie das Target angeben:
# Makefile
make test TARGETS="//runsc:version_test"
# Bazel
bazel test //runsc:version_test
Einige Pakete unterstützen das direkte Ausführen von Tests unter macOS. Zum Zeitpunkt dieses Schreibens erfordert gVisor bazel 8, das Sie über Homebrew installieren können:
brew install bazel@8
# Sie können dann die Tests ausführen, z. B.:
$(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 getDieses Projekt verwendet [bazel][bazel] zum Bauen und Verwalten von Abhängigkeiten.
Ein synthetischer go-Branch wird gepflegt, der aus Bequemlichkeit mit
Standard-go-Tooling kompatibel ist. Dies ist nützlich für externe Pakete und
Bibliotheken, die von gVisor-Unterpaketen abhängen (z. B. Userspace-Netzwerking
über Netstack), um gVisor-Go-Code in ihre Go-Projekte zu importieren.
Wählen Sie diesen Branch explizit mit der go-Branch-Abfrage aus. @latest löst
master auf, was Bazel erfordert und nicht mit Standard-Go-Tooling kompatibel ist:
go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go
HINWEIS: runsc-Builds aus diesem Branch werden nicht unterstützt. gVisor
und runsc benötigen mehrere Binaries (von denen einige nicht einmal in Go
geschrieben sind), um zu funktionieren. Der go-Branch wird nach bestem Bemühen
unterstützt, und die direkte Entwicklung auf diesem Branch wird nicht unterstützt.
Die Entwicklung sollte auf dem master-Branch erfolgen, der dann in den
go-Branch übernommen wird.
Siehe GOVERNANCE.md für Informationen zur Projekt-Governance.
Siehe ADOPTERS.md für eine Liste bekannter Produktionsnutzer und Adopter.
Die [gvisor-users-Mailingliste][gvisor-users-list] und die [gvisor-dev-Mailingliste][gvisor-dev-list] sind gute Ausgangspunkte für Fragen und Diskussionen.
Siehe SECURITY.md.
Siehe Contributing.md.