GKE Sandbox

Container, die unbekannten oder nicht vertrauenswürdigen Code in Google Kubernetes Engine-Clustern (GKE) ausführen, stellen ein potenzielles Sicherheitsrisiko für den Hostkernel Ihrer Knoten dar. Sie können Ihren Hostkernel vor diesen Bedrohungen schützen, indem Sie den Code vom Kernel isolieren. In diesem Dokument wird beschrieben, wie die GKE-Sandbox diese Isolationsschicht mithilfe von Technologien wie gVisor und MicroVMs erstellt.

Dieses Dokument richtet sich an Sicherheitsexperten, die die Angriffsfläche in ihren GKE-Knoten reduzieren und ihre Knoten vor nicht vertrauenswürdigem Code schützen möchten. Sie sollten bereits mit Folgendem vertraut sein:

Sandboxing in GKE

Die auf Knoten installierte Containerlaufzeit, z. B. containerd, bietet einen gewissen Grad an Isolierung zwischen den Prozessen des Containers und dem auf dem Knoten ausgeführten Kernel. Die Containerlaufzeit wird allerdings häufig als privilegierter Nutzer auf dem Knoten ausgeführt und hat somit Zugriff auf die meisten Systemaufrufe, die an den Hostkernel gehen.

In Kubernetes und GKE werden laufende Container durch Sandboxing isoliert, um die potenziellen Auswirkungen von Exploits oder Fehlern zu begrenzen, die andere Container oder die Containerlaufzeit betreffen. Sie können Container in Sandboxes ausführen, um den Kernel der zugrunde liegenden Compute Engine-Instanz vor nicht vertrauenswürdigem oder unbekanntem Code zu schützen. Sandboxing ist auch eine gute Maßnahme mit gestaffelten Sicherheitsebenen, um hochwertige Container vor anderen Arbeitslasten zu schützen. Mit GKE Sandbox können Sie Arbeitslasten in Sandboxes ausführen.

Mögliche Bedrohungen

Ein Fehler in der Containerlaufzeit oder im Host-Kernel könnte dazu führen, dass ein in einem Container ausgeführter Prozess den Container „verlässt“ und den Kernel des Knotens beeinträchtigt. Mehrmandantenfähige Cluster und Cluster, in denen Container nicht vertrauenswürdige Arbeitslasten ausführen, sind anfälliger für Sicherheitslücken als andere Cluster. Beispiele:

  • Organisationen, die Nutzern das Hochladen und Ausführen von Code ermöglichen, z. B. SaaS-Anbieter und Webhosting-Anbieter.
  • KI-Agenten, die Code generieren und ausführen, oft ohne Aufsicht.

Die von GKE Sandbox verwendeten Sandboxing-Technologien tragen dazu bei, die folgenden potenziellen Auswirkungen von Container-Escapes zu minimieren:

  • Schädlicher oder fehlerhafter Code, der den Hostkernel zum Absturz bringt und den Knoten herunterfährt.
  • Bösartige Mandanten, die Daten eines anderen Mandanten im Arbeitsspeicher oder auf einem Laufwerk exfiltrieren.
  • Nicht vertrauenswürdige Arbeitslasten, die auf andere Google Cloud -Dienste oder Clustermetadaten zugreifen.

Sandbox-Technologien in GKE

GKE Sandbox unterstützt die folgenden Sandbox-Technologien, die jeweils einen anderen Ansatz zur Isolierung von Arbeitslasten verwenden und sich für verschiedene Anwendungsfälle eignen:

  • gVisor: Eine Neuimplementierung der Linux-Kernel-API im Nutzerbereich, für die keine erhöhten Berechtigungen erforderlich sind. Der Userspace-Kernel und die Containerlaufzeit implementieren die meisten Systemaufrufe neu und stellen sie im Namen des Hostkernels bereit. Der direkte Zugriff auf den Hostkernel ist eingeschränkt. Weitere Informationen zur Funktionsweise des Gastkernels finden Sie im gVisor-Architekturleitfaden.

  • MicroVMs: einfache virtuelle Maschinen, auf denen ein vollständiger Linux-Kernel und ein vollständiges Betriebssystem ausgeführt werden. Jeder Pod wird in einer eigenen MicroVM ausgeführt, die eine strikte Isolation von anderen Pods und vom Hostknoten bietet. GKE Sandbox verwendet die Open-Source-Software Kata Containers und den Virtual Machine Monitor (VMM) Cloud Hypervisor, um MicroVMs zu erstellen und zu verwalten.

In der folgenden Tabelle sind die wichtigsten Unterschiede zwischen MicroVMs und gVisor zusammengefasst. Anhand dieser Informationen können Sie die geeignete Sandbox-Technologie für Ihren Anwendungsfall auswählen.
Funktion MicroVMs gVisor
Kernel-Zugriff Vollständiger Linux-Kernel Teilmenge der Linux-Kernel-Syscalls
Isolationsebene Vollständige Hardwarevirtualisierung mit einem dedizierten Gastkernel Syscall-Abfangen in einem Userspace-Kernel
CPU- und Arbeitsspeicher-Overhead Fester Overhead von 250 mCPU und 130 MiB Arbeitsspeicher für jeden Pod Dynamischer Overhead mit geringem Basisspeicher für den Userspace-Kernel
Beginn Etwa ein bis zwei Sekunden Weniger als 100 ms
GKE-Knotenkonfiguration Erfordert GKE-Standardknoten mit aktivierter verschachtelter Virtualisierung Verfügbar in GKE-Standardknotenpools und GKE Autopilot-Knoten. Standardmäßig in GKE Autopilot-Clustern aktiviert.
Unterstützung von Knoten-Images Container-Optimized OS (cos_containerd) oder Ubuntu Nur Container-Optimized OS (cos_containerd)
Kompatibilität von Maschinentypen Unterstützt von x86-Maschinenserien, die verschachtelte Virtualisierung unterstützen (nicht unterstützt auf E2- oder Arm-VMs) Wird von den meisten x86-CPUs, der Arm-Architektur und Beschleuniger-Maschinentypen unterstützt
Beschleunigerunterstützung Unterstützt keine GPUs oder TPUs. Unterstützt bestimmte GPU-Modelle und TPU-Versionen.
Beispielanwendungsfälle
  • KI-Agenten, die Code ohne Aufsicht generieren und ausführen
  • Autonomer Code, der in Browsern ausgeführt wird, z. B. Puppeteer
  • Arbeitslasten, die Zugriff auf den vollständigen Linux-Kernel erwarten
  • Arbeitslasten, die eine große Anzahl von Systemaufrufen mit geringem Overhead generieren, beispielsweise sehr viele kleine E/A-Vorgänge
  • Nicht vertrauenswürdige Anwendungen oder Anwendungen von Drittanbietern, die Laufzeiten wie Rust, Java, Python, PHP, Node.js oder Golang verwenden
  • Webserver-Frontends, Caches oder Proxys
  • Anwendungen, die externe Medien oder Daten mithilfe von CPUs verarbeiten
  • GPU- und TPU-intensive Arbeitslasten
  • KI-Inferenzarbeitslasten, die beliebige Eingaben verarbeiten oder Code ausführen
  • Trainingsarbeitslasten, die große Datasets und Modelle von Drittanbietern verarbeiten

Wenn Sie KI-Agenten-Arbeitslasten ausführen, die nicht vertrauenswürdigen Code ausführen, können Sie MicroVMs oder gVisor mit Agent Substrate in GKE oder Agent Sandbox in GKE verwenden. Einen Vergleich dieser Orchestrierungsmodelle finden Sie unter Architektur für KI-Agenten-Arbeitslasten in GKE planen.

Weitere Informationen, die Ihnen bei der Entscheidung helfen können, welche Anwendungen in einem bestimmten Sandbox-Typ ausgeführt werden sollen, finden Sie unter Einschränkungen.

So funktioniert das Anfordern von Sandboxes

So führen Sie eine Anwendung in einer Sandbox aus:

  1. Aktivieren Sie eine Sandbox-Technologie in Knoten, indem Sie ComputeClasses verwenden, um die Knoten automatisch zu erstellen, oder indem Sie Knotenpools manuell erstellen.
  2. Fordern Sie eine Sandbox für Pods an, indem Sie die entsprechende RuntimeClass für diesen Sandbox-Typ verwenden, z. B. gvisor oder microvm. Weitere Informationen finden Sie unter Isolierung von Arbeitslasten mit GKE Sandbox härten.

Die GKE plant die Pods auf Knoten, die die angeforderte Sandbox-Technologie verwenden, die dann die Ausführung der Anwendung in der Sandbox übernimmt. Sie können optional Pods, die keine Sandboxes anfordern, auf Knoten ausführen, für die GKE Sandbox aktiviert ist. Verwenden Sie dazu Knotenauswahl und Toleranzen. Dies ist nützlich für vertrauenswürdige Arbeitslasten wie Monitoring-Tools, die Sie auf jedem Knoten ausführen möchten.

Zusätzliche Sicherheitsempfehlungen

Bei Verwendung von GKE Sandbox sollten Sie außerdem folgende Empfehlungen beachten:

  • Geben Sie Ressourcenlimits für alle Container an, die in einer Sandbox ausgeführt werden. Dies schützt vor dem Risiko, dass eine fehlerhafte oder böswillige Anwendung die Ressourcen des Knotens an sich bindet und andere Anwendungen oder Systemprozesse, die auf dem Knoten ausgeführt werden, negativ beeinflusst.

  • Wenn Sie die Workload Identity-Föderation für GKE verwenden, blockieren Sie den Zugriff auf Clustermetadaten mithilfe der Netzwerkrichtlinie, um den Zugriff auf 169.254.169.254 zu blockieren. Dies schützt vor dem Risiko, dass eine schädliche Anwendung auf Informationen zugreift, die auf potenziell private Daten wie Projekt-ID, Knotenname und Zone verweisen. Die Workload Identity-Föderation für GKE ist in GKE-Autopilot-Clustern immer aktiviert.

Beschränkungen

GKE Sandbox funktioniert gut mit vielen Anwendungen, jedoch nicht mit allen. Dieser Abschnitt enthält weitere Informationen zu den aktuellen Einschränkungen von GKE Sandbox.

GPUs in GKE Sandbox

Sie können GPU-Arbeitslasten in Sandboxes mit gVisor ausführen. gVisor deckt nicht alle NVIDIA-Treiber-Sicherheitslücken ab, schützt jedoch vor Sicherheitslücken in Linux-Kerneln. Verwenden Sie die GPU-Zeitfreigabe nicht in Pods in einer Sandbox, da die GPU zwischen Pods nicht vollständig isoliert ist. Weitere Informationen zum Schutz von GPU-Arbeitslasten durch gVisor finden Sie im GPU-Supporthandbuch.

Die folgenden Einschränkungen gelten für GPU-Arbeitslasten in GKE Sandbox:

  • MicroVMs unterstützen keine GPUs.
  • Für gVisor gelten die folgenden Einschränkungen:
    • Nur CUDA-Arbeitslasten werden unterstützt.
    • Es wird nur eine Teilmenge der verfügbaren GPU-Modelle unterstützt. Weitere Informationen finden Sie unter Unterstützung von GPU-Modellen.
    • Für jede GKE-Version werden nur die NVIDIA-Treiberversionen latest und default unterstützt. Andere Treiberversionen funktionieren möglicherweise nicht.
    • Nicht alle GPU-Funktionen wie RDMA oder IMEX werden unterstützt. Je nach Kundenanforderungen unterstützt gVisor möglicherweise bestimmte Funktionen von Fall zu Fall. Wenn Sie Support für ein bestimmtes Feature benötigen, öffnen Sie einen Supportfall oder stellen Sie eine gVisor-Featureanfrage.

Unterstützung von GPU-Modellen

In der folgenden Tabelle wird die Unterstützung für verschiedene GPU-Modelle in GKE Sandbox beschrieben:

Modell Vorschau GA-Support Hinweise
  • NVIDIA RTX Pro 6000
    		•
  • Maschinentypen mit einer oder mehreren GPUs: 1.34.1-gke.2037001 und höher
  • Maschinentypen mit weniger als einer GPU: nicht unterstützt
    		• - -
  • NVIDIA GB200
  • NVIDIA B200
  • NVIDIA H200 141 GB
    		•
  • 1.34.0-gke.1713000 und höher
    		•  - -
  • NVIDIA H100 80 GB
  • NVIDIA A100 80 GB
  • NVIDIA A100 40 GB
  • NVIDIA L4
  • NVIDIA T4
    		•  -
  • 1.29.15-gke.1134000 und höher
  • 1.30.11-gke.1093000 und höher
  • 1.31.7-gke.1149000 und höher
  • 1.32.2-gke.1182003 und höher
    		•  Seit der ersten Veröffentlichung unterstützt.
  • NVIDIA V100
  • NVIDIA P100 (Ende der Unterstützung steht bevor)
    		•  nicht unterstützt nicht unterstützt V100 und P100 verwenden proprietäre Treiber und werden nicht unterstützt.
  • NVIDIA T4 VWS
  • NVIDIA L4 VWS
    		•  - - GKE Sandbox unterstützt keine Windows- oder Ubuntu-Knotentypen, die für virtuelle Workstation-Knoten erforderlich sind.

    TPUs in GKE Sandbox

    In GKE-Version 1.31.3-gke.1111001 und höher können Sie TPU-Arbeitslasten in Sandboxes mit gVisor ausführen. gVisor deckt nicht alle TPU-Treiber-Sicherheitslücken ab, schützt jedoch vor Sicherheitslücken in Linux-Kerneln. Weitere Informationen zum Schutz von TPU-Arbeitslasten durch das gVisor-Projekt finden Sie im TPU-Supporthandbuch.

    Für TPU-Arbeitslasten in GKE Sandbox gelten die folgenden Einschränkungen:

    • MicroVMs unterstützen keine TPUs.

    • gVisor unterstützt die folgenden TPU-Versionen:

      • V4pod
      • V4lite
      • V5litepod
      • V5pod
      • V6e

    Knotenkonfiguration

    Für die Knoten, die GKE Sandbox verwenden, gelten die folgenden Einschränkungen:

    • gVisor und MicroVMs unterstützen nur Linux-Knoten. Windows Server-Knoten werden nicht unterstützt.
    • gVisor unterstützt nur das Container-Optimized OS-Knoten-Image. MicroVMs unterstützen die Knoten-Images für Container-Optimized OS und Ubuntu.
    • Für MicroVMs muss die verschachtelte Virtualisierung auf den Knoten aktiviert sein. Es gelten alle Anforderungen und Einschränkungen der verschachtelten Virtualisierung.
    • In Standard-Clustern können Sie GKE Sandbox nicht im Standardknotenpool aktivieren. Der Cluster muss immer mindestens einen Knotenpool haben, der GKE Sandbox nicht verwendet. Dieser Knotenpool muss mindestens einen Knoten enthalten, auch wenn all Ihre Arbeitslasten in einer Sandbox ausgeführt werden. Diese Einschränkung dient dazu, Systemdienste von nicht vertrauenswürdigen Arbeitslasten zu trennen.

    Zugriff auf Clustermetadaten

    Wenn Ihre Knoten den gVisor-Sandbox-Typ verwenden, können Pods auf den Knoten nicht auf Clustermetadaten auf der Betriebssystemebene des Knotens zugreifen. Pods können auch nicht auf Google Cloud-Dienste zugreifen, es sei denn, Sie verwenden die Workload Identity-Föderation für GKE, um den Pod-Identitäten Rollen zuzuweisen.

    Diese Einschränkung gilt nicht für den Sandbox-Typ „microVM“. Wenn Sie den Zugriff auf Clustermetadaten von Pods in MicroVMs verhindern möchten, verwenden Sie eine NetworkPolicy, die ausgehenden Traffic an 169.254.169.252/32 über Port 988 oder in Clustern, die GKE Dataplane V2 verwenden, an 169.254.169.254/32 über Port 80 ablehnt.

    SMT ist möglicherweise deaktiviert

    Einstellungen für gleichzeitiges Multithreading (SMT), auch als Hyper-Threading auf Intel-CPUs bezeichnet, werden verwendet, um Schwachstellen in Nebenkanälen zu vermeiden, die sich die gemeinsame Nutzung des Kernzustands durch Threads zunutze machen, wie z. B. MDS-Sicherheitslücken (Microarchitectural Data Sampling).

    Um Seitenkanalangriffe zu minimieren, verwendet gVisor Linux Core Scheduling. Die SMT-Einstellungen bleiben von den Standardwerten unberührt. Linux Core Scheduling gilt nur für Pods, die in gVisor-Sandboxes ausgeführt werden.

    Die Standardeinstellung für SMT oder Hyper-Threading für einen Maschinentyp hängt davon ab, wie anfällig die Maschine für MDS ist:

    • Autopilot-Pods, die die Scale-Out-ComputeClass verwenden: SMT ist immer deaktiviert.
    • Maschinentypen, die Intel-Prozessoren verwenden: Hyper-Threading ist standardmäßig deaktiviert.
    • Maschinentypen, die AMD-Prozessoren verwenden: SMT ist standardmäßig aktiviert.
    • Maschinentypen, die nur einen Thread pro Kern verwenden, z. B. Arm-Prozessoren: keine SMT-Unterstützung. Alle angeforderten vCPUs sind sichtbar.

    SMT aktivieren

    In GKE-Standardknotenpools können Sie SMT aktivieren, wenn es für den ausgewählten Maschinentyp standardmäßig deaktiviert ist. Jede vCPU wird Ihnen in Rechnung gestellt, unabhängig davon, ob Sie SMT aktiviert oder deaktiviert haben. Weitere Informationen finden Sie unter Preise beim Ändern der Anzahl der Threads pro Kern. Führen Sie einen der folgenden Schritte aus, um die SMT-Einstellung zu ändern:

    • Legen Sie beim Erstellen eines GKE Sandbox-Knotenpools, der gVisor verwendet, das Flag --threads-per-core fest:

      gcloud container node-pools create smt-enabled \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --threads-per-core=2 \
    --sandbox=type=gvisor
      • CLUSTER_NAME: der Name eines vorhandenen Clusters, in dem Sie den neuen Knotenpool erstellen möchten.
      • LOCATION: die Compute Engine-Region oder -Zone des Clusters.
      • MACHINE_TYPE ist der Maschinentyp.

    • Verwenden Sie ein DaemonSet, um SMT für einen vorhandenen Knotenpool zu aktivieren:

      1. Fügen Sie einem vorhandenen Knotenpool, der gVisor verwendet, das Knotenlabel cloud.google.com/gke-smt-disabled=false hinzu:

        gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --node-labels=cloud.google.com/gke-smt-disabled=false

        Ersetzen Sie Folgendes:

        • NODE_POOL_NAME: der Name des vorhandenen Knotenpools.
        • CLUSTER_NAME: der Name eines vorhandenen Clusters, in dem Sie den neuen Knotenpool erstellen möchten.
        • LOCATION: die Compute Engine-Region oder -Zone des Clusters.

      2. Stellen Sie das DaemonSet bereit. Das DaemonSet wird nur auf Knoten mit dem Label cloud.google.com/gke-smt-disabled=false ausgeführt.

        kubectl create -f \
    https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yaml

      3. Prüfen Sie, ob die DaemonSet-Pods ausgeführt werden.

        kubectl get pods --selector=name=enable-smt -n kube-system

        Die Ausgabe sieht etwa so aus:

        NAME               READY     STATUS    RESTARTS   AGE
enable-smt-2xnnc   1/1       Running   0          6m

      4. Prüfen Sie, ob die Logs der Pods SMT has been enabled enthalten:

        kubectl logs enable-smt-2xnnc enable-smt -n kube-system

    Leistungsspektrum

    Gilt für Standardcluster

    Container werden standardmäßig daran gehindert, RAW-Sockets zu öffnen, um das Risiko von böswilligen Angriffen zu verringern. Bestimmte netzwerkbezogene Tools wie ping und tcpdump erstellen im Rahmen ihres Kernvorgangs Raw-Sockets. Damit RAW-Sockets aktiviert werden, müssen Sie die Funktion NET_RAW explizit in den Sicherheitskontext des Containers aufnehmen:

    spec:
  containers:
  - name: my-container
    securityContext:
      capabilities:
        add: ["NET_RAW"]

    Wenn Sie GKE Autopilot verwenden, verhindert Google Cloud aufgrund der Auswirkungen dieser Funktion auf die Sicherheit, dass Sie die Berechtigung NET_RAW zu Containern hinzufügen.

    Externe Abhängigkeiten

    Gilt für Autopilot- und Standardcluster

    Nicht vertrauenswürdiger Code, der in der Sandbox ausgeführt wird, kann externe Dienste wie Datenbankserver, APIs, andere Container und CSI-Treiber erreichen. Diese Dienste werden außerhalb der Sandbox-Isolierung ausgeführt und müssen einzeln geschützt werden. Ein Angreifer kann Sicherheitslücken in diesen Diensten ausnutzen, um aus der Sandbox auszubrechen. Sie müssen berücksichtigen, welches Risiko und welche Auswirkungen die Erreichbarkeit dieser Dienste durch den in der Sandbox ausgeführten Code mit sich bringt. Ergreifen Sie die erforderlichen Maßnahmen, um sie zu schützen.

    Dazu gehören Dateisystemimplementierungen für Container-Volumes wie ext4- und CSI-Treiber. CSI-Treiber werden außerhalb der Sandbox-Isolierung ausgeführt und haben möglicherweise privilegierten Zugriff auf den Host und die Dienste. Ein Exploit in diesen Treibern kann sich auf den Host-Kernel auswirken und den gesamten Knoten gefährden. Wir empfehlen, den CSI-Treiber innerhalb eines Containers nur mit minimal erforderlichen Berechtigungen auszuführen, um die Gefährdung im Falle eines Exploits zu reduzieren. GKE Sandbox unterstützt die Verwendung des CSI-Treibers für nichtflüchtigen Speicher von Compute Engine.

    Inkompatible Features

    Für GKE Sandbox gelten die folgenden Funktionseinschränkungen:

    • Die folgenden Einschränkungen gelten sowohl für gVisor- als auch für MicroVM-Sandboxes:

      • Cloud Service Mesh wird für Sandboxes in Autopilot-Clustern nicht unterstützt.
      • Sicherheitsmodule für den Linux-Kernel wie seccomp, AppArmor, SELinux, das Flag „No New Privileges“, die bidirektionale Bereitstellungsausbreitung und der procMount-Pod-Sicherheitskontext werden in Pods in einer Sandbox nicht unterstützt.
      • Messwerte zur Speichernutzung auf Containerebene werden nicht unterstützt. Die Pod-Speichernutzung wird jedoch unterstützt.
      • Tools, die sich in den Linux-Hostkernel einklinken, um Containeraktivitäten zu überwachen (z. B. Security Command Center Container Threat Detection, Falco oder Tetragon), können Systemaufrufe, die in Sandbox-Containern in gVisor- oder MicroVM-Sandboxen ausgeführt werden, nicht beobachten oder melden. In MicroVM-Sandboxes können Sie eBPF-Monitoring-Tools als privilegierten Sidecar-Container im Pod ausführen, um den Gastkernel der MicroVM zu überwachen.

    • Die folgenden Einschränkungen gelten nur für gVisor-Sandboxes:

      • Container, die den privilegierten Modus verwenden, werden nicht unterstützt.
      • Rohblock-Volumes werden nicht unterstützt.
      • Portweiterleitung, z. B. mit kubectl port-forward, wird nicht unterstützt.
      • Hostpath-Speicher wird nicht unterstützt.
      • Das Festlegen von sysctl-Kernel-Parametern wird nicht unterstützt.
      • CPU- und Arbeitsspeicherlimits werden nur auf Pods mit den QoS-Klassen Guaranteed oder Burstable angewendet und nur dann, wenn CPU- und Arbeitsspeicherlimits für alle Container im Pod angegeben sind.
      • Die Open-Source-gVisor-Features seccheck, pod-init-config und benutzerdefinierte Unix-Domain-Socket-Telemetrie-Streaming-Features (UDS) werden in GKE Sandbox-Knotenpools nicht unterstützt oder sind nicht konfigurierbar.

    • Die folgenden Einschränkungen gelten nur für MicroVM-Sandboxes:

      • Pods, die die Einstellung hostNetwork: true verwenden, werden nicht unterstützt. Pods, die in einer MicroVM-Sandbox ausgeführt werden und die Einstellung hostNetwork: true verwenden, können nicht auf Ressourcen außerhalb des Pods zugreifen.
      • Diagnosetools, die auf Socket-Level-Tracing basieren, können nur auf die Netzwerkschnittstellen zugreifen, die an die MicroVM angehängt sind.

    Nächste Schritte