GKE Sandbox

Auf dieser Seite 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. Beispielsweise führen mehrmandantenfähige Cluster wie Software-as-a-Service-Anbieter (SaaS) häufig unbekannten Code aus, der von ihren Nutzern gesendet wurde. GKE Sandbox ist auch eine nützliche Maßnahme mit gestaffelten Sicherheitsebenen zum Ausführen hochwertiger Container.

GKE Sandbox verwendet das Open-Source-Projekt gVisor. In diesem Thema wird gVisor ausführlich behandelt. Wenn Sie jedoch mehr Informationen wünschen, lesen Sie die offizielle Dokumentation zu gVisor.

Eine Anleitung 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 dieser 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
  • GPU-intensive Arbeitslasten

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:

  • Es wird nur die NVIDIA-Treiberversion latest in einer bestimmten GKE-Version unterstützt. Autopilot-Cluster installieren automatisch NVIDIA-Treiberversionen, die GKE Sandbox unterstützen.
  • Nur CUDA-Arbeitslasten werden unterstützt.
  • Die folgenden GPU-Modelle werden unterstützt: nvidia-tesla-t4, nvidia-tesla-a100, nvidia-a100-80gb, nvidia-l4 und nvidia-h100-80gb.

Sie können GKE Sandbox ohne zusätzliche Kosten mit GPU-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 Standard-Cluster

  • 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 Standard-Cluster

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 \
  --machine-type=MACHINE_TYPE \
  --threads-per-core=2 \
  --sandbox type=gvisor
  • CLUSTER_NAME den Namen des vorhandenen 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 \
    --machine-type=MACHINE_TYPE \
    --node-labels=cloud.google.com/gke-smt-disabled=false \
    --image-type=cos_containerd \
    --sandbox type=gvisor

  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 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 Standard-Cluster

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 Standard-Cluster

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 Standard-Cluster

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 Standard-Cluster

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