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.254zu 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 derdefault-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 |
|---|---|---|---|
|
|
- |
|
Seit der ersten Einführung unterstützt. |
|
|
|
- | - |
|
|
|
- | - |
|
|
|
- | - |
|
|
- | - | In Kürze verfügbar |
|
|
nicht unterstützt | nicht unterstützt | Die V100- und P100-GPUs verwenden proprietäre Treiber und werden nicht unterstützt. |
|
|
- | - | {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_NAMEist der Name eines vorhandenen Clusters, in dem Sie den neuen Knotenpool erstellen möchten.LOCATION: die Compute Engine-Region oder -Zone des Clusters.MACHINE_TYPEist 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
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=gvisorErsetzen Sie Folgendes:
CLUSTER_NAMEist der Name eines vorhandenen Clusters, in dem Sie den neuen Knotenpool erstellen möchten.LOCATION: die Compute Engine-Region oder -Zone des Clusters.MACHINE_TYPEist der Maschinentyp.
Stellen Sie das DaemonSet im Knotenpool bereit. Das DaemonSet wird nur auf Knoten mit dem Label
cloud.google.com/gke-smt-disabled=falseausgeführt.kubectl create -f \ https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yamlPrüfen Sie, ob die DaemonSet-Pods ausgeführt werden.
kubectl get pods --selector=name=enable-smt -n kube-systemDie Ausgabe sieht etwa so aus:
NAME READY STATUS RESTARTS AGE enable-smt-2xnnc 1/1 Running 0 6mPrüfen Sie, ob die Logs der Pods
SMT has been enabledenthalten.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:
- Messwerte zur Speichernutzung auf Containerebene. Die Pod-Speichernutzung wird jedoch unterstützt.
- hostPath-Speicher
- CPU- und Arbeitsspeicherlimits werden nur auf Guaranteed Pods und Burstable Pods angewendet und nur dann, wenn CPU- und Arbeitsspeicherlimits für alle im Pod ausgeführten Container angegeben sind.
- Container, die im privilegierten Modus ausgeführt werden
- VolumeDevices
- Portweiterleitung
- Sicherheitsmodule für den Linux-Kernel wie Seccomp, Apparmor oder Selinux, Sysctl,
NoNewPrivileges, bidirektionale MountPropagation oder ProcMount. FSGroup wird in GKE Version 1.22 und höher unterstützt.
Cloud Service Mesh wird für GKE Sandbox-Pods in Autopilot-Clustern nicht unterstützt.
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