Sicheres Laden von Kernelmodulen konfigurieren

Mit dem sicheren Laden von Kernelmodulen in Google Kubernetes Engine (GKE) können Sie Arbeitslasten ausführen, für die signierte, externe Kernelmodule (Out-of-Tree, OOT) auf sicheren, für Container-Optimized OS-Images erforderlich sind. Das sichere Laden von Kernelmodulen trägt dazu bei, den Sicherheitsstatus Ihrer Cluster und Knotenpools zu verbessern, da Sie mehr Kontrolle über das Laden von Modulen auf CPU- oder TPU-Knoten mit Signaturprüfung haben.

Funktionsweise des sicheren Ladens von Kernelmodulen

Standardmäßig verwenden GKE-Knoten je nach Knotentyp unterschiedliche für Container-Optimized OS-Images mit unterschiedlichen Sicherheitskonfigurationen:

  • CPU- und TPU-Knoten: verwenden ein für Container-Optimized OS-Image mit aktiviertem Linux Security Module (LSM) Loadpin. Loadpin schränkt das Laden von OOT-Kernelmodulen ein. Diese Einstellung ist sicher, verhindert aber das Laden von OOT-Modulen.
  • GPU-Knoten: verwenden ein für Container-Optimized OS-Image mit deaktiviertem Loadpin. Mit dieser Einstellung können OOT-Module geladen werden, z. B. NVIDIA-Treiber installiert werden. Sie ist aber standardmäßig weniger sicher.

Sie aktivieren das sichere Laden von Kernelmodulen mit der Einstellung NodeKernelModuleLoading.Policy in der LinuxNodeConfig für einen Knotenpool oder mit dem Flag --enable-kernel-module-signature-enforcement beim Erstellen oder Aktualisieren eines Clusters oder Knotenpools. Wenn Sie die Richtlinie auf ENFORCE_SIGNED_MODULES festlegen, wird Loadpin in Ihren CPU- oder TPU-Knotenpools aktiviert, aber so konfiguriert, dass das Laden von Kernelmodulen außerhalb des Root-Dateisystems zulässig ist. Module müssen signiert sein und das System lässt nur von Google signierte Module zu.

Wann sollte das sichere Laden von Kernelmodulen verwendet werden?

Verwenden Sie das sichere Laden von Kernelmodulen, wenn Sie von Google signierte OOT-Kernelmodule wie benutzerdefinierte Treiber oder Dateisysteme wie Lustre auf einen beliebigen GKE-Knotentyp laden müssen. Mit dieser Funktion können Sie diese Module verwenden, ohne den Sicherheitsstatus des Knotens zu beeinträchtigen. Sie können beispielsweise einen erforderlichen Treiber auf einen CPU-Knoten laden, ohne den weniger restriktiven GPU-Image-Typ verwenden zu müssen.

Anforderungen und Einschränkungen

Wenn Sie das sichere Laden von Kernelmodulen in Ihren Knotenpools aktivieren, gelten die folgenden Anforderungen und Einschränkungen:

  • Unterstützte Module: Nur von Google signierte OOT-Module sind zulässig.
  • cgroup v2: Der Knotenpool muss cgroup v2 verwenden. Die Kubernetes Engine API lehnt Anfragen zum Aktivieren dieser Richtlinie für Knotenpools ab, die cgroup v1 verwenden. Weitere Informationen finden Sie in der Kubernetes-Dokumentation zu cgroup.
  • GKE-Version: Diese Funktion ist in GKE-Cluster versionen 1.34.1-gke.2364000 und höher verfügbar.
  • GPU-Image-Typen: Nur CPU- und TPU-Images unterstützen das sichere Laden von Kernelmodulen. GPUs werden nicht unterstützt.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

Richtlinie für das sichere Laden von Kernelmodulen konfigurieren

Sie können die Richtlinie für das sichere Laden von Kernelmodulen für einzelne Cluster oder als Knotenpooleinstellung konfigurieren. Die verfügbaren Richtlinien sind:

  • ENFORCE_SIGNED_MODULES: Erzwingt, dass alle externen Kernelmodule von Google signiert sind. Für diese Richtlinie muss der Knotenpool cgroup v2 verwenden.
  • DO_NOT_ENFORCE_SIGNED_MODULES: Ermöglicht das Laden beliebiger Kernelmodule, signiert oder nicht signiert. Das ist das Standardverhalten.

Wenn Sie keine Richtlinie angeben, verwendet GKE das Standardverhalten, bei dem keine signierten Module erzwungen werden.

Sicheres Laden von Kernelmodulen in einem Cluster aktivieren

Führen Sie einen der folgenden Schritte aus, um das sichere Laden von Kernelmodulen in einem Cluster zu aktivieren:

  • Führen Sie den folgenden Befehl aus, um die Funktion in einem neuen Cluster zu aktivieren:

    Standard 

    gcloud container clusters create CLUSTER_NAME \
   --location=LOCATION \
   --project=PROJECT_ID \
   --enable-kernel-module-signature-enforcement

    Autopilot 

    gcloud container clusters create-auto CLUSTER_NAME \
   --location=LOCATION \
   --project=PROJECT_ID \
   --enable-kernel-module-signature-enforcement

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name des neuen Clusters.
    • LOCATION: Die Region oder Zone für den Cluster.
    • PROJECT_ID: Ihre Projekt-ID.

  • Führen Sie den folgenden Befehl aus, um die Funktion in einem vorhandenen Cluster zu aktivieren:

    gcloud container clusters update CLUSTER_NAME \
     --location=LOCATION \
     --project=PROJECT_ID \
     --enable-kernel-module-signature-enforcement

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: Die Region oder Zone für den Cluster.
    • PROJECT_ID: Ihre Projekt-ID.

    Wenn Sie einen vorhandenen Cluster aktualisieren, werden die Knoten bei der nächsten verfügbaren Gelegenheit neu erstellt, es sei denn, dies wird durch ein Wartungsfenster verhindert.

Sicheres Laden von Kernelmodulen in einem Knotenpool aktivieren

Führen Sie einen der folgenden Schritte aus, um das sichere Laden von Kernelmodulen in einem Knotenpool zu aktivieren:

  • Führen Sie den folgenden Befehl aus, um die Funktion in einem neuen Knotenpool zu aktivieren:

    gcloud container node-pools create NODEPOOL_NAME \
     --cluster=CLUSTER_NAME \
     --location=LOCATION \
     --project=PROJECT_ID \
     --enable-kernel-module-signature-enforcement

    Ersetzen Sie Folgendes:

    • NODEPOOL_NAME ist der Name des neuen Knotenpools.
    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: Die Region oder Zone für den Cluster.
    • PROJECT_ID: Ihre Projekt-ID.

  • Führen Sie den folgenden Befehl aus, um die Funktion in einem vorhandenen Knotenpool zu aktivieren:

    gcloud container node-pools update NODEPOOL_NAME \
     --cluster=CLUSTER_NAME \
     --location=LOCATION \
     --project=PROJECT_ID \
     --enable-kernel-module-signature-enforcement

    Ersetzen Sie Folgendes:

    • NODEPOOL_NAME: der Name des Knotenpools, der aktualisiert werden soll.
    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: Die Region oder Zone für den Cluster.
    • PROJECT_ID: Ihre Projekt-ID.

Bestätigen, dass die Richtlinie für das sichere Laden von Kernelmodulen festgelegt ist

Führen Sie den folgenden Befehl aus, um zu bestätigen, dass eine Richtlinie für einen Cluster festgelegt ist:

gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID

Prüfen Sie in der Ausgabe den Abschnitt linuxNodeConfig. Im Feld kernelModuleLoading wird die aktuelle Richtlinie angezeigt:

...
config:
  linuxNodeConfig:
    kernelModuleLoading:
      policy: ENFORCE_SIGNED_MODULES
    cgroupMode: CGROUP_MODE_V2

Sicheres Laden von Kernelmodulen deaktivieren

Führen Sie einen der folgenden Schritte aus, um das sichere Laden von Kernelmodulen zu deaktivieren:

  • Führen Sie den folgenden Befehl aus, um die Funktion in einem Cluster zu deaktivieren:

    gcloud container clusters update CLUSTER_NAME \
     --location=LOCATION \
     --project=PROJECT_ID \
     --no-enable-kernel-module-signature-enforcement

  • Führen Sie den folgenden Befehl aus, um die Funktion in einem vorhandenen Knotenpool zu deaktivieren:

    gcloud container node-pools update NODEPOOL_NAME \
     --cluster=CLUSTER_NAME \
     --location=LOCATION \
     --project=PROJECT_ID \
     --no-enable-kernel-module-signature-enforcement

Nächste Schritte

  • Informationen darüber, wie sich die Sicherheit eines Clusters erhöhen lässt.