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

Ausführliche Informationen zum Aktivieren von GKE Sandbox finden Sie unter GKE Sandbox konfigurieren.

Überblick

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 docker oder 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 Knotenpool aktivieren, wird für jeden Pod, der auf einem Knoten in diesem Knotenpool ausgeführt wird, eine Sandbox erstellt. Darüber hinaus wird verhindert, dass Knoten, auf denen Pods in einer Sandbox ausgeführt werden, auf andere Google Cloud-Dienste oder Clustermetadaten zugreifen.

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

Zusätzliche Sicherheitsempfehlungen

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

  • Es wird dringend empfohlen, dass Sie Ressourcenlimits für alle Container festlegen, 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.

Einschrä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.

Knotenpoolkonfiguration

  • Sie können GKE Sandbox nicht im Standardknotenpool aktivieren.
  • 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.
  • Der Knotenpool kann die Maschinentypen e2-micro, e2-small und e2-medium nicht verwenden.

Zugriff auf Clustermetadaten

  • Knoten mit Pods, die in einer Sandbox ausgeführt werden, haben keinen Zugriff auf Clustermetadaten, die sich auf Betriebssystemebene des Knotens befinden.
  • Sie können 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. Mithilfe der Arbeitslastidentität können Sie Pods Zugriff auf Google Cloud-Dienste gewähren.

Hyper-Threading ist deaktiviert

Auf gVisor-Knoten ist Hyper-Threading auf allen Architekturen standardmäßig deaktiviert. Dadurch werden Sicherheitslücken in Seitenkanälen minimiert, die den Kernzustand zwischen Hyper-Threads ausnutzen. Beispiel: Sicherheitslücke im Rahmen von Microarchitectural Data Sampling (MDS). So aktivieren Sie Hyper-Threading für einen Knotenpool:

  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. Es aktiviert Hyper-Threading und startet dann den Knoten neu.

    kubectl create -f \
        https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yaml
    
  3. Nachdem der Knoten neu gestartet wurde, müssen Sie prüfen, ob sich die DaemonSet-Pods im Ausführungsmodus befinden.

    kubectl get pods --selector=name=enable-smt -n kube-system
    
  4. Sie sollten eine Antwort ähnlich der folgenden erhalten:

    NAME               READY     STATUS    RESTARTS   AGE
    enable-smt-2xnnc   1/1       Running   0          6m
    
  5. Prüfen Sie, ob die Logs der Pods SMT has been enabled enthalten.

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

Funktionen

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"]

Externe Abhängigkeiten

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. Sie können den CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine zusammen mit der GKE Sandbox verwenden, da dies unterstützt wird.

Inkompatible Features

Derzeit ist es nicht möglich, GKE Sandbox zusammen mit den folgenden Kubernetes-Features zu verwenden:

Arbeitslasteigenschaften

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

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

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

Weitere Informationen