gvisor

Was ist gVisor?

gVisor bietet eine starke Isolationsschicht zwischen laufenden Anwendungen und dem Host-Betriebssystem. Es ist ein Anwendungskernel, der eine Linux-ähnliche Schnittstelle implementiert. Im Gegensatz zu Linux ist er in einer speichersicheren Sprache (Go) geschrieben und läuft im Userspace.

gVisor enthält eine Laufzeitumgebung der Open Container Initiative (OCI) namens runsc, die die Arbeit mit vorhandenen Container-Werkzeugen erleichtert. Die runsc-Laufzeitumgebung integriert sich in Docker und Kubernetes und macht es einfach, Sandbox-Container auszuführen.

Was ist gVisor nicht?

• gVisor ist kein Syscall-Filter (z. B. seccomp-bpf) und auch kein Wrapper um Linux-Isolationsprimitive (z. B. firejail, AppArmor usw.).
• gVisor ist im üblichen Sinne des Begriffs auch keine VM (z. B. VirtualBox, QEMU).

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 normaler Userspace-Anwendungen beibehält.

Warum gibt es gVisor?

Container sind keine Sandbox. Obwohl Container die Art und Weise revolutioniert haben, wie wir Anwendungen entwickeln, paketieren und bereitstellen, ist es keine gute Idee, sie ohne zusätzliche Isolation zum Ausführen von nicht vertrauenswürdigem oder potenziell schädlichem Code zu verwenden. Die Verwendung eines einzigen, gemeinsamen Kernels ermöglicht zwar Effizienz- und Leistungsgewinne, bedeutet aber auch, dass ein Container-Ausbruch mit einer einzigen Sicherheitslücke möglich ist.

gVisor ist ein Anwendungskernel für Container. Er begrenzt die für die Anwendung erreichbare Angriffsfläche des Host-Kernels, während die Anwendung weiterhin Zugriff auf alle erwarteten Funktionen erhält. Im Gegensatz zu den meisten Kerneln setzt gVisor keinen festen Satz physischer Ressourcen voraus und benötigt ihn auch nicht; stattdessen nutzt es vorhandene Funktionen des Host-Kernels und läuft als normaler Prozess. Mit anderen Worten: gVisor implementiert Linux mithilfe von 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 Zugriffsbereich eines Dienstes einschränken. Man sollte stets vorsichtig sein, welche Daten einem Container zur Verfügung gestellt werden.

Dokumentation

Benutzerdokumentation und technische Architektur, einschließlich Schnellstartanleitungen, finden Sie unter gvisor.dev.

Installation aus dem Quellcode

gVisor lässt sich auf x86_64 und ARM64 erstellen. Andere Architekturen könnten in Zukunft verfügbar werden.

Für diese Anleitung sind bazel und andere Build-Abhängigkeiten in einem Build-Container gekapselt. Es ist möglich, bazel direkt zu verwenden oder make help für die Standard-Targets einzugeben.

Voraussetzungen

Stellen Sie sicher, dass die folgenden Abhängigkeiten installiert sind:

• Linux 5.6+
• Docker-Version 17.09.0 oder höher

Erstellen

Erstellen 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 erwartet, und extrahieren 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 Target angeben:

make build TARGETS="//pkg/tcpip:tcpip"

Direkt mit Bazel erstellen (ohne Docker)

Die direkte Verwendung von Bazel wird aufgrund des zusätzlichen Aufwands nicht empfohlen, aber für den Einstieg gilt:

• Schauen Sie sich das Build-Dockerfile für die kanonische Liste der benötigten Abhängigkeiten an.
• Installieren und verwenden Sie bazelisk. Stellen Sie andernfalls sicher, dass Ihre Bazel-Version mit der in der Datei .bazelversion angegebenen übereinstimmt.

Nach dem Einrichten der Abhängigkeiten ähnelt die Verwendung von Bazel dem Makefile:

bazel build -c opt //debian:gvisor-release-tar

Testen

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 Target angeben:

# Makefile
make test TARGETS="//runsc:version_test"
# Bazel
bazel test //runsc:version_test

Mac OS

Einige Pakete unterstützen das direkte Ausführen von Tests auf macOS. Zum Zeitpunkt der Erstellung dieses Textes benötigt 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}/...

Verwendung von go get

Dieses Projekt verwendet bazel zum Erstellen und Verwalten von Abhängigkeiten. Aus Bequemlichkeit wird ein synthetischer go-Zweig gepflegt, der mit dem Standard-go-Tooling kompatibel ist. Dies ist nützlich für externe Pakete und Bibliotheken, die von gVisor-Teilpaketen abhängen (z. B. Userspace-Netzwerk über Netstack), um gVisor-Go-Code in ihre Go-Projekte zu importieren.

Wählen Sie diesen Zweig explizit mithilfe der go-Zweigabfrage aus. @latest löst master auf, was Bazel erfordert und nicht mit dem Standard-Go-Tooling kompatibel ist:

go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go

HINWEIS: runsc-Builds aus diesem Zweig 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-Zweig wird nach besten Kräften unterstützt, eine direkte Entwicklung an diesem Zweig wird jedoch nicht unterstützt. Die Entwicklung sollte auf dem master-Zweig erfolgen, der dann in den go-Zweig übernommen wird.

Community & Governance

Informationen zur Projekt-Governance finden Sie in GOVERNANCE.md.

Die gvisor-users-Mailingliste und die gvisor-dev-Mailingliste sind gute Anlaufstellen für Fragen und Diskussionen.

Sicherheitsrichtlinie

Siehe SECURITY.md.

Mitwirken

Siehe Contributing.md.