GKE Sandbox

In diesem Dokument wird beschrieben, wie die GKE Sandbox den Hostkernel auf Ihren Knoten schützt, wenn Container unbekannten oder nicht vertrauenswürdigen Code im Pod ausführen. In diesem Dokument wird davon ausgegangen, dass Sie mit Folgendem vertraut sind:

  • gVisor, das Open-Source-Projekt, das von GKE Sandbox verwendet wird.

Dieses Dokument richtet sich an Sicherheitsexperten, die mehr über die Vorteile von GKE Sandbox erfahren möchten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Sie können GKE Sandbox verwenden, wenn Sie mehrmandantenfähige Cluster ausführen, da Software-as-a-Service-Anbieter (SaaS) häufig unbekannten Code ausführen, der von ihren Nutzern gesendet wurde. GKE Sandbox ist auch eine nützliche Maßnahme mit gestaffelten Sicherheitsebenen zum Ausführen hochwertiger Container.

Informationen zum Aktivieren und Verwenden von GKE Sandbox finden Sie unter GKE Sandbox konfigurieren.

Übersicht

Mithilfe einer zusätzlichen Sicherheitsebene verhindert GKE Sandbox, dass der Hostkernel auf Ihren Clusterknoten durch nicht vertrauenswürdigen Code beeinträchtigt wird. Bevor die Funktionsweise von GKE Sandbox erläutert wird, sollten Sie sich aber mit den potenziellen Risiken vertraut machen, die durch GKE Sandbox gemindert werden.

Eine Containerlaufzeit wie 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.

Mögliche Bedrohungen

Mehrmandantenfähige Cluster und Cluster, deren Container nicht vertrauenswürdige Arbeitslasten ausführen, sind anfälliger für Sicherheitslücken als andere Cluster. Beispiele hierfür sind SaaS-Anbieter, Webhostinganbieter oder andere Organisationen, die ihren Nutzern das Hochladen und Ausführen von Code erlauben. Eine Schwachstelle in der Containerlaufzeit oder im Hostkernel kann dazu führen, dass ein in einem Container ausgeführter Prozess den Container "verlässt" und den Kernel des Knotens so beeinträchtigt, dass der Knoten eventuell ausfällt.

Es besteht auch die Möglichkeit, dass ein böswilliger Mandant einen solchen Defekt ausnutzt, um Zugriff auf die Daten eines anderen Mandanten im Arbeitsspeicher oder auf dem Laufwerk zu erlangen und diese Daten unbefugt weiterzugeben.

Schließlich könnte eine nicht vertrauenswürdige Arbeitslast auf andere Google Cloud-Dienste oder Clustermetadaten zugreifen und damit eine Bedrohung darstellen.

Minimierung potenzieller Bedrohungen durch GKE Sandbox

gVisor ist eine Userspace-Neuimplementierung der Linux Kernel API, für die keine erhöhten Berechtigungen erforderlich sind. In Verbindung mit einer Containerlaufzeit wie containerd implementiert der Userspace-Kernel die Mehrheit der Systemaufrufe neu und verarbeitet sie im Auftrag des Hostkernels. Der direkte Zugriff auf den Hostkernel ist eingeschränkt. Ausführliche Informationen zu dieser Funktionsweise finden Sie im gVisor Architecture Guide. Aus Sicht des Containers ist gVisor nahezu transparent und erfordert keine Änderungen an der containerisierten Anwendung.

Wenn Sie GKE Sandbox in einem Pod in Autopilot-Clustern anfordern, führt GKE diesen Pod in einer Sandbox aus. In GKE Standard: Wenn Sie GKE Sandbox auf Knoten aktivieren, werden alle Pods, die auf diesen Knoten ausgeführt werden, in Sandboxes ausgeführt.

Jede Sandbox verwendet einen eigenen Userspace-Kernel. Vor diesem Hintergrund können Sie anhand des gewünschten Isolierungsgrads und den Eigenschaften Ihrer Anwendungen entscheiden, wie Sie Ihre Container in Pods gruppieren.

GKE Sandbox eignet sich besonders gut für die folgenden Arten von Anwendungen. Weitere Informationen zur Entscheidung, welche Anwendungen in einer Sandbox auszuführen sind, finden Sie unter Einschränkungen.

  • Nicht vertrauenswürdige Anwendungen 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
  • Arbeitslasten für maschinelles Lernen, die CPUs verwenden
  • CPU-intensive oder arbeitsspeicherintensive Anwendungen

KI-/ML-Arbeitslasten oder ‑Dienste erfordern oft eine schnellere Bereitstellung in der Produktion. gVisor wurde entwickelt, um vor ganzen Klassen häufiger Linux-Sicherheitslücken zu schützen. Mit GKE Sandbox können Sie die Sicherheit von GPU- und TPU-intensiven Arbeitslasten ohne größere Änderungen an Ihrem Code verbessern. Wichtige Anwendungsfälle, in denen GKE Sandbox gut geeignet ist, sind für KI-/ML-Arbeitslasten üblich:

  • GPU- und TPU-intensive Arbeitslasten.
  • Dienste, die nicht vertrauenswürdigen Nutzercode akzeptieren und ausführen.
  • Dienste, die beliebige Nutzereingaben verarbeiten.
  • Arbeitslasten, bei denen große Drittanbieter-Datasets und ‑Modelle verarbeitet werden.
  • Anwendungen, die Bibliotheken von Drittanbietern verwenden.

Weitere Informationen zum Design und zur Sicherheit des Beschleunigerzugriffs finden Sie in den gVisor-Leitfäden zu GPUs und TPU.

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

In GKE-Version 1.29.2-gke.1108000 und höher unterstützt GKE Sandbox die Verwendung von NVIDIA-GPUs.

GKE Sandbox deckt nicht alle NVIDIA-Treiber-Sicherheitslücken ab, schützt jedoch vor Sicherheitslücken in Linux-Kerneln. Weitere Informationen zum Schutz von GPU-Arbeitslasten durch das gVisor-Projekt finden Sie im GPU-Supporthandbuch.

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

  • Nur CUDA-Arbeitslasten werden unterstützt.
  • Eine Teilmenge der in GKE unterstützten GPUs wird in GKE Sandbox unterstützt. Weitere Informationen finden Sie in der Supporttabelle.
  • gVisor unterstützt nur bestimmte NVIDIA-Treiberversionen. GKE Sandbox sorgt dafür, dass sowohl der latest- als auch der default-Treiber für jede unterstützte GPU für jede GKE-Version kompatibel sind. Die Funktion anderer Treiber wird nicht garantiert.
  • Nicht alle GPU-Funktionen funktionieren nativ (z.B. RDMA oder IMEX). GPU-Funktionen werden je nach Kundenanforderung fallweise unterstützt. Erstellen Sie ein Support-Ticket oder melden Sie einen Fehler in den GitHub-Problemen von gVisor.

Sie können GKE Sandbox ohne zusätzliche Kosten mit GPU-Arbeitslasten verwenden.

Unterstützung von GPU-Modellen in GKE Sandbox

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

Modell Vorschau GA-Support Hinweise
  • NVIDIA T4
  • NVIDIA L4
  • NVIDIA A100 40 GB
  • NVIDIA A100 80 GB
  • NVIDIA H100 80 GB
  • -
  • 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 H200 141 GB
  • 1.34.0-gke.1713000 und höher
  • - -
  • NVIDIA B200
  • 1.34.0-gke.1713000 und höher
  • - -
  • NVIDIA GB200
  • 1.34.0-gke.1713000 und höher
  • - -
  • NVIDIA RTX PRO 6000
  • - - In Kürze verfügbar
  • NVIDIA V100
  • NVIDIA P100
  • nicht unterstützt nicht unterstützt Die V100- und P100-GPUs 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 Virtual Workstation-Knoten erforderlich sind.

    TPUs in GKE Sandbox

    In GKE-Version 1.31.3-gke.1111001 und höher unterstützt GKE Sandbox die Verwendung von TPUs.

    GKE Sandbox 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.

    Die folgenden TPU-Hardwareversionen werden unterstützt: V4pod, V4lite, V5litepod, V5pod und V6e.

    Sie können GKE Sandbox ohne zusätzliche Kosten mit TPU-Arbeitslasten verwenden.

    Knotenpoolkonfiguration

    Gilt für Standardcluster

    • Sie können GKE Sandbox nicht unter Windows Server-Knotenpools verwenden.
    • Sie können GKE Sandbox im Standardknotenpool nicht aktivieren, um Systemdienste, die im Standardknotenpool ausgeführt werden, mithilfe von GKE Sandbox von nicht vertrauenswürdigen Arbeitslasten zu trennen.
    • Wenn Sie GKE Sandbox verwenden, muss der Cluster mindestens zwei Knotenpools umfassen. Sie müssen immer mindestens einen Knotenpool haben, in dem GKE Sandbox deaktiviert ist. Dieser Knotenpool muss mindestens einen Knoten enthalten, auch wenn all Ihre Arbeitslasten in einer Sandbox ausgeführt werden.
    • GKE-Versionen vor 1.24.2-gke.300 unterstützen die Maschinentypen e2-micro, e2-small und e2-medium nicht. Die GKE-Version 1.24.2-gke.300 und höher unterstützt diese Maschinentypen.
    • Knoten müssen das Knoten-Image Container-Optimized OS mit containerd (cos_containerd) verwenden.

    Zugriff auf Clustermetadaten

    Gilt für Autopilot- und Standardcluster

    • Knoten mit Pods, die in einer Sandbox ausgeführt werden, haben keinen Zugriff auf Clustermetadaten, die sich auf Betriebssystemebene des Knotens befinden.
    • In GKE Standard können Sie reguläre Pods auf einem Knoten mit aktivierter GKE Sandbox ausführen. Standardmäßig können diese Pods jedoch nicht auf Google Cloud -Dienste oder Clustermetadaten zugreifen.
    • Verwenden Sie die Workload Identity-Föderation für GKE, um Pods Zugriff auf Google Cloud -Dienste zu gewähren.

    SMT ist möglicherweise deaktiviert

    Gilt für Autopilot- und Standardcluster

    Gleichzeitige Multithreading (SMT)-Einstellungen werden verwendet, um Schwachstellen in Nebenkanälen zu vermeiden, die sich die gemeinsame Nutzung des Kernzustands durch Threads zunutze machen, wie z.B. Schwachstellen MDS-Sicherheitslücken (Microarchitectural Data Sampling).

    In GKE-Versionen 1.25.5-gke.2500 oder höher und 1.26.0-gke.2500 oder höher ist gVisor so konfiguriert, dass Linux Core Scheduling verwendet wird, um Seitenkanalangriffe zu minimieren. Die SMT-Einstellungen bleiben von der Standardeinstellung unberührt. Core Scheduling wird nur für Arbeitslasten verwendet, die mit gVisor ausgeführt werden.

    Ab der GKE-Version 1.24.2-gke.300 wird SMT nach Maschinentyp konfiguriert, je nachdem, wie anfällig der Computer für MDS ist:

    • Autopilot-Pods, die auf der Scale-Out-Computing-Klasse ausgeführt werden: SMT deaktiviert.

    • Maschinentypen mit Intel-Prozessoren: SMT ist standardmäßig deaktiviert.

    • Maschinentypen ohne Intel-Prozessoren: SMT ist standardmäßig aktiviert.

    • Maschinentypen mit nur einem Thread pro Kern: keine SMT-Unterstützung. Alle angeforderten vCPUs sind sichtbar.

    Vor Version 1.24.2-gke.300 ist SMT auf allen Maschinentypen deaktiviert.

    SMT aktivieren

    Gilt für Standardcluster

    In GKE-Standardclustern können Sie SMT aktivieren, wenn es auf dem ausgewählten Maschinentyp deaktiviert ist. Jede vCPU wird Ihnen in Rechnung gestellt, unabhängig davon, ob Sie SMT aktiviert oder deaktiviert haben. Preisinformationen finden Sie unter Compute Engine-Preise.

    GKE-Version 1.24.2-gke.300 und höher

    Legen Sie beim Erstellen eines GKE Sandbox-Knotenpools 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 ist 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.

    Weitere Informationen zu --threads-per-core finden Sie unter Anzahl der Threads pro Kern festlegen.

    GKE-Versionen vor 1.24.2-gke.300

    1. Erstellen Sie in Ihrem Cluster einen neuen Knotenpool mit dem Knotenlabel cloud.google.com/gke-smt-disabled=false:

      gcloud container node-pools create smt-enabled \
          --cluster=CLUSTER_NAME \
          --location=LOCATION \
          --machine-type=MACHINE_TYPE \
          --node-labels=cloud.google.com/gke-smt-disabled=false \
          --image-type=cos_containerd \
          --sandbox type=gvisor
      

      Ersetzen Sie Folgendes:

      • CLUSTER_NAME ist 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.
    2. Stellen Sie das DaemonSet im Knotenpool 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 RAW-Sockets als Teil ihrer Kernfunktionalität. 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 , dass Sie die Berechtigung NET_RAW zu Containern hinzufügen, da dies Auswirkungen auf die Sicherheit hat.

    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

    Sie können GKE Sandbox nicht mit den folgenden Kubernetes-Features verwenden:

    Arbeitslasteigenschaften

    Gilt für Autopilot- und Standardcluster

    Das Hinzufügen einer zusätzlichen Ebene der Indirektion für den Zugriff auf den Knotenkernel bringt Leistungseinbußen mit sich. Den größten Nutzen bietet GKE Sandbox bei Verwendung umfangreicher mehrmandantenfähiger Cluster, bei denen Isolation wichtig ist. Beachten Sie beim Testen Ihrer Arbeitslasten mit GKE Sandbox die folgenden Richtlinien.

    Systemaufrufe

    Gilt für Autopilot- und Standardcluster

    Arbeitslasten, die eine große Anzahl von Systemaufrufen mit geringem Overhead generieren, beispielsweise sehr viele kleine E/A-Vorgänge, erfordern bei Ausführung in einer Sandbox möglicherweise mehr Systemressourcen. Daher müssen Sie gegebenenfalls leistungsstärkere Knoten verwenden oder Ihren Cluster um zusätzliche Knoten erweitern.

    Direkter Zugriff auf Hardware oder Virtualisierung

    Gilt für Autopilot- und Standardcluster

    Wenn Ihre Arbeitslast eines der folgenden Features benötigt, eignet sich GKE Sandbox unter Umständen nicht, da damit der direkte Zugriff auf den Hostkernel des Knotens verhindert wird:

    • Direkter Zugriff auf die Hardware des Knotens
    • Virtualisierungsfeatures auf Kernelebene
    • Privilegierte Container

    Nächste Schritte