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 verringern 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 Isolation 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 sich auf andere Container oder die Container-Laufzeit auswirken. 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 es einem Prozess, der in einem Container ausgeführt wird, ermöglichen, aus dem Container „auszubrechen“ und den Kernel des Knotens zu beeinträchtigen. Multi-Tenant-Cluster und Cluster, in denen Container nicht vertrauenswürdige Arbeitslasten ausführen, sind stärker Sicherheitslücken ausgesetzt als andere Cluster. Beispiele:

  • Organisationen, die Nutzern das Hochladen und Ausführen von Code ermöglichen, z. B. SaaS- und Webhosting-Anbieter.
  • KI-Agents, 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 Host-Kernel zum Absturz bringt und den Knoten herunterfährt.
  • Bösartige Mandanten, die Daten eines anderen Mandanten exfiltrieren, die sich im Arbeitsspeicher oder auf einem Laufwerk befinden.
  • 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 Nutzerbereichs-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 Gast-Kernels finden Sie im gVisor Architecture Guide.

  • MicroVMs: Leichtgewichtige 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 Cloud Hypervisor Virtual Machine Monitor (VMM), um Micro-VMs zu erstellen und zu verwalten.

In der folgenden Tabelle sind die wichtigsten Unterschiede zwischen gVisor und MicroVMs zusammengefasst. Anhand dieser Informationen können Sie die passende Sandbox-Technologie für Ihren Anwendungsfall auswählen.

gVisor MicroVMs
Kernel-Zugriff Teilmenge der Linux-Kernel-Syscalls Vollständiger Linux-Kernel
Isolationsebene Syscall-Abfangen in einem Userspace-Kernel Vollständige Hardwarevirtualisierung mit einem dedizierten Gastkernel
CPU- und Arbeitsspeicher-Overhead Dynamischer Overhead mit geringem Basisspeicher für den Userspace-Kernel Fester Overhead von 250 mCPU und 130 MiB Arbeitsspeicher für jeden Pod
Beginn Weniger als 200 ms Etwa ein bis zwei Sekunden
GKE-Knotenkonfiguration Verfügbar in allen Standard-Knotenpools und Autopilot-Knoten. Standardmäßig in Autopilot-Clustern aktiviert. Nur auf Knoten verfügbar, auf denen die verschachtelte Virtualisierung aktiviert ist.
Unterstützung von Knoten-Images Nur Container-Optimized OS Container-Optimized OS oder Ubuntu
Kompatibilität von Maschinentypen Wird von den meisten CPUs, der Arm-Architektur und Beschleuniger-Maschinentypen unterstützt. Wird nur von Maschinentypen unterstützt, die verschachtelte Virtualisierung unterstützen.
Unterstützung von Beschleunigern Unterstützt bestimmte GPU-Modelle und TPU-Versionen. Unterstützt keine GPUs oder TPUs.
Privilegierte Container Nicht unterstützt. Unterstützt. Privilegierte Container erhalten Root-Zugriff nur auf das Gastbetriebssystem in der Micro-VM und nicht auf den Hostknoten.
Beispielanwendungsfälle
  • Nicht vertrauenswürdige oder Drittanbieteranwendungen, die Laufzeiten wie Rust, Java, Python, PHP, Node.js oder Golang verwenden
  • Webserver-Front-Ends, 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
  • KI-Agents, 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 benötigen
  • Arbeitslasten, die eine große Anzahl von Systemaufrufen mit geringem Overhead generieren, z. B. sehr viele kleine E/A-Vorgänge

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

So fordern Sie Sandboxes an

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.

GKE plant die Pods auf Knoten, die die angeforderte Sandbox-Technologie verwenden. Diese übernimmt dann die Ausführung der Anwendung in der Sandbox. Sie können optional Pods, die keine Sandboxes anfordern, auf Knoten ausführen, für die GKE Sandbox aktiviert ist. Verwenden Sie dazu Knotenselektoren 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 Sandbox-Pods, da die GPU nicht vollständig zwischen Pods 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 im Einzelfall. Wenn Sie Unterstützung für ein bestimmtes Feature benötigen, eröffnen Sie einen Supportfall oder erstellen Sie eine gVisor-Featureanfrage.

Unterstützung für GPU-Modelle

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 Einführung unterstützt.
  • NVIDIA V100
  • NVIDIA P100 (Ende des Supports steht bevor)
    		•  nicht unterstützt nicht unterstützt Für die V100 und P100 werden proprietäre Treiber verwendet, die nicht unterstützt werden.
  • NVIDIA T4 VWS
  • NVIDIA L4 VWS
    		•  - - GKE Sandbox unterstützt keine Windows- oder Ubuntu-Knotentypen, die für Virtual 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 Micro-VMs 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 Standardclustern 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 auf Port 988 oder in Clustern, die GKE Dataplane V2 verwenden, an 169.254.169.254/32 auf 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 die 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 mit Intel-Prozessoren: Hyper-Threading ist standardmäßig deaktiviert.
    • Maschinentypen mit AMD-Prozessoren: 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 Standard-Knotenpools 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, wenn Sie die Anzahl der Threads pro Kern ändern. 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.

    • So aktivieren Sie SMT auf einem vorhandenen Knotenpool mit einem DaemonSet:

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

        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 ihrer Kernfunktion 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, Google Cloud 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:

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

    • 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-Tracing basieren, können nur auf die Netzwerkschnittstellen zugreifen, die an die MicroVM angehängt sind.

    Nächste Schritte