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 Zusammenarbeit mit bestehenden Container-Tools erleichtert. Die runsc-Runtime
lässt sich in Docker und Kubernetes integrieren und macht das Ausführen von sandboxed
Containern einfach.
Was ist gVisor nicht?
seccomp-bpf) und auch kein Wrapper über
Linux-Isolationsprimitive (z. B. firejail, AppArmor usw.).gVisor verfolgt einen eigenständigen dritten Ansatz und bietet viele Sicherheitsvorteile von VMs, während der geringere Ressourcenbedarf, der schnelle Start und die Flexibilität regulärer Userspace-Anwendungen erhalten bleiben.
Warum gibt es gVisor?
Container sind keine [Sandbox][sandbox]. Obwohl Container die Art und Weise revolutioniert haben, wie wir Anwendungen entwickeln, paketieren und bereitstellen, ist es keine gute Idee, sie zum Ausführen nicht vertrauenswürdigen oder potenziell bösartigen Codes ohne zusätzliche Isolation zu verwenden. Ein einzelner, gemeinsam genutzter Kernel ermöglicht zwar Effizienz- und Leistungsgewinne, bedeutet aber auch, dass ein Container-Ausbruch 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 verlangt sie; stattdessen nutzt er 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 Werkzeugen verwechselt werden, die Container gegen externe Bedrohungen härten, zusätzliche Integritätsprüfungen bereitstellen oder den Zugriffsumfang für einen Dienst begrenzen. Man sollte stets sorgfältig darauf achten, welche Daten einem Container zur Verfügung gestellt werden.
Dokumentation
Benutzerdokumentation und technische Architektur, einschließlich Schnellstartanleitungen, finden Sie unter [gvisor.dev][gvisor-dev].
Installation aus dem Quellcode
gVisor lässt sich auf x86_64 und ARM64 bauen. Andere Architekturen könnten in Zukunft verfügbar werden.
Für diese 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 Standardziele 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-Binärdateien enthält, die runsc in einem
gvisor-bin/-Verzeichnis neben sich selbst erwartet, und entpacken Sie es dann nach /usr/local/bin:
make release-tarball DESTINATION=bin/
sudo tar -C /usr/local/bin -xf bin/gvisor.tar.bz2
Um bestimmte Bibliotheken oder Binärdateien zu erstellen, können Sie das Ziel 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 beim Makefile:
bazel build -c opt //debian:gvisor-release-tar-bz2
Um die Standard-Testsuiten auszuführen, können Sie Folgendes verwenden:
make unit-tests
make tests
Um bestimmte Tests auszuführen, können Sie das Ziel 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
# 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 getDieses Projekt verwendet [bazel][bazel], um Builds und Abhängigkeiten zu verwalten. Ein synthetischer go-Branch wird gepflegt, der aus praktischen Gründen mit der Standard-go-Toolchain kompatibel ist. Dies ist nützlich für externe Pakete und Bibliotheken, die von gVisor-Unterpaketen abhängen (z. B. Userspace-Netzwerk ü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 zu master auf, was Bazel erfordert und nicht mit der Standard-Go-Toolchain 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 Binärdateien (von denen einige nicht einmal in Go geschrieben sind), um
zu funktionieren. Der go-Branch wird im Rahmen des Möglichen („best effort“) 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 Releases.
Siehe Contributing.md.