Isolierung von Arbeitslasten mit GKE Sandbox härten

Auf dieser Seite wird beschrieben, wie Sie mit GKE Sandbox den Hostkernel auf Ihren Knoten schützen, wenn Container unbekannten oder nicht vertrauenswürdigen Code im Pod ausführen.

Verfügbarkeit von GKE Sandbox

GKE Sandbox kann in Autopilot-Clustern mit GKE-Version 1.27.4-gke.800 und höher verwendet werden. Fahren Sie mit Mit GKE Sandbox arbeiten fort, um mit dem Bereitstellen von Autopilot-Arbeitslasten in einer Sandbox zu beginnen.

Wenn Sie GKE Sandbox in neuen oder vorhandenen GKE Standardclustern verwenden möchten, müssen Sie die GKE Sandbox manuell im Cluster aktivieren.

GPU-Arbeitslasten sind in der Vorschau in GKE Sandbox ab Version 1.29.2-gke.11080000 verfügbar.

Hinweise

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 diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

GKE Sandbox in einem neuen Standardcluster aktivieren

Der Standardknotenpool, der bei der Erstellung eines neuen Clusters erstellt wird, kann GKE Sandbox nicht verwenden, wenn er der einzige Knotenpool im Cluster ist, da von GKE verwaltete Systemarbeitslasten getrennt von nicht vertrauenswürdigen Sandbox-Arbeitslasten ausgeführt werden müssen. Um GKE Sandbox während der Clustererstellung zu aktivieren, müssen Sie dem Cluster mindestens einen zusätzlichen Knotenpool hinzufügen.

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --accelerator=type=GPU_TYPE,gpu-driver-version=latest \
  --image-type=cos_containerd \
  --sandbox type=gvisor

GKE Sandbox in einem vorhandenen Standardcluster aktivieren

Sie können GKE Sandbox in einem vorhandenen Standard-Cluster aktivieren. Dazu fügen Sie einen neuen Knotenpool hinzu und aktivieren das Feature für diesen Knotenpool.

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --machine-type=MACHINE_TYPE \
  --image-type=cos_containerd \
  --sandbox type=gvisor

gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --node-version=NODE_VERSION \
  --machine-type=MACHINE_TYPE \
  --accelerator=type=GPU_TYPE,gpu-driver-version=latest \
  --image-type=cos_containerd \
  --sandbox type=gvisor

Optional: Monitoring und Logging aktivieren

Optional empfiehlt es sich, Cloud Logging und Cloud Monitoring auf dem Cluster zu aktivieren, damit gVisor-Meldungen protokolliert werden. Diese Dienste sind für neue Cluster standardmäßig aktiviert.

Sie können die Google Cloud Console verwenden, um diese Features auf einem vorhandenen Cluster zu aktivieren.

1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie auf den Namen des Clusters, den Sie ändern möchten.

3. Klicken Sie unter Features im Feld Cloud Logging auf edit Cloud Logging bearbeiten.

4. Klicken Sie das Kästchen Cloud Logging aktivieren an.

5. Klicken Sie auf Änderungen speichern.

6. Wiederholen Sie dieselben Schritte für die Felder Cloud Monitoring und Managed Service for Prometheus, um diese Features zu aktivieren.

GKE Sandbox in Autopilot und Standard verwenden

In Autopilot-Clustern und Standard-Clustern mit aktivierter GKE Sandbox fordern Sie eine Sandbox-Umgebung für einen Pod an. Geben Sie dazu die RuntimeClass gvisor in der Pod-Spezifikation an.

Für Autopilot-Cluster benötigen Sie die GKE-Version 1.27.4-gke.800 oder höher.

Anwendung in einer Sandbox ausführen

Damit ein Deployment auf einem Knoten mit aktivierter GKE Sandbox ausgeführt wird, legen Sie für spec.template.spec.runtimeClassName den Wert gvisor fest, wie im folgenden Beispiel gezeigt:

# httpd.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      runtimeClassName: gvisor
      containers:
      - name: httpd
        image: httpd

Erstellen Sie das Deployment:

kubectl apply -f httpd.yaml

Der Pod wird auf einem Knoten mit aktivierter GKE Sandbox bereitgestellt. Suchen Sie zum Prüfen der Bereitstellung den Knoten, auf dem der Pod bereitgestellt wird:

kubectl get pods

Die Ausgabe sieht in etwa so aus:

NAME                    READY   STATUS    RESTARTS   AGE
httpd-db5899bc9-dk7lk   1/1     Running   0          24s

Suchen Sie in der Ausgabe den Namen des Pods und prüfen Sie dann den Wert für RuntimeClass:

kubectl get pods POD_NAME -o jsonpath='{.spec.runtimeClassName}'

Die Ausgabe lautet gvisor.

Alternativ können Sie die RuntimeClass eines jeden Pods auflisten und nach den Pods suchen, die auf gvisor festgelegt sind:

kubectl get pods -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'

Die Ausgabe sieht so aus:

POD_NAME: gvisor

Diese Methode zur Prüfung des Pods auf Ausführung in einer Sandbox ist vertrauenswürdig, da sie sich nicht auf Daten aus der Sandbox selbst stützt. Alle aus der Sandbox gemeldeten Daten sind nicht vertrauenswürdig, da sie fehlerhaft sein oder aus böswilligen Aktivitäten stammen können.

Pod mit GPUs in GKE Sandbox ausführen

Wenn Sie eine GPU-Arbeitslast in GKE Sandbox ausführen möchten, fügen Sie Ihrem Manifest das Feld runtimeClassName: gvisor hinzu, wie in den folgenden Beispielen gezeigt:

• Beispielmanifest für GPU-Pods im Standardmodus:

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-gpu-pod
  spec:
    runtimeClassName: gvisor
    containers:
    - name: my-gpu-container
      image: nvidia/samples:vectoradd-cuda10.2
      resources:
        limits:
        nvidia.com/gpu: 1
  

• Beispielmanifest für GPU-Pods im Autopilot-Modus:

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-gpu-pod
  spec:
    runtimeClassName: gvisor
    nodeSelector:
      cloud.google.com/gke-gpu-driver-version: "latest"
      cloud.google.com/compute-class: "Accelerator"
      cloud.google.com/gke-accelerator: nvidia-tesla-t4
    containers:
    - name: my-gpu-container
      image: nvidia/samples:vectoradd-cuda10.2
      resources:
        limits:
          nvidia.com/gpu: 1
  

Sie können alle GPU-Pods im Autopilot- oder Standard-Modus ausführen, die die Anforderungen an Version und GPU-Typ in GKE Sandbox erfüllen, indem Sie dem Manifest das Feld runtimeClassName: gvisor hinzufügen. Eine Anleitung zum Ausführen von GPU-Pods in GKE finden Sie in den folgenden Ressourcen:

• GPU-Arbeitslasten in Autopilot bereitstellen
• GPUs in GKE-Standardknotenpools ausführen

Regulären Pod zusammen mit Pods ausführen, die in einer Sandbox ausgeführt werden

Die Schritte in diesem Abschnitt gelten für Arbeitslasten im Standardmodus. Sie müssen keine regulären Pods zusammen mit den Sandbox-Pods im Autopilot-Modus ausführen, da das Autopilot-Preismodell die manuelle Optimierung der Anzahl der auf den Knoten geplanten Pods überflüssig macht.

Nachdem Sie GKE Sandbox in einem Knotenpool aktiviert haben, können Sie vertrauenswürdige Anwendungen auf diesen Knoten ohne Verwendung einer Sandbox mithilfe von Knotenmarkierungen und -toleranzen ausführen. Diese Pods werden als "reguläre Pods" bezeichnet, um sie von Pods zu unterscheiden, die in einer Sandbox ausgeführt werden.

Wie Pods, die in einer Sandbox ausgeführt werden, werden auch reguläre Pods daran gehindert, auf andere Google Cloud-Dienste oder Clustermetadaten zuzugreifen. Dieser Schutz ist Teil der Knotenkonfiguration. Wenn die regulären Pods oder Pods, die in einer Sandbox ausgeführt werden, Zugriff auf Google Cloud-Dienste benötigen, verwenden Sie die Workload Identity-Föderation für GKE.

GKE Sandbox fügt Knoten, die in einer Sandbox ausgeführte Pods ausführen können, das folgende Label und die folgende Markierung hinzu:

labels:
  sandbox.gke.io/runtime: gvisor

taints:
- effect: NoSchedule
  key: sandbox.gke.io/runtime
  value: gvisor

Neben Einstellungen für die Knotenaffinität und -toleranz im Pod-Manifest wendet GKE Sandbox die folgende Knotenaffinität und -toleranz auf alle Pods an, für die RuntimeClass auf gvisor festgelegt ist:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: sandbox.gke.io/runtime
          operator: In
          values:
          - gvisor

tolerations:
  - effect: NoSchedule
    key: sandbox.gke.io/runtime
    operator: Equal
    value: gvisor

Wenn Sie einen regulären Pod auf einem Knoten mit aktivierter GKE Sandbox planen möchten, wenden Sie die beschrieben Knotenaffinität und -toleranz manuell in Ihrem Pod-Manifest an.

• Wenn Ihr Pod auf Knoten mit aktivierter GKE Sandbox ausgeführt werden kann, fügen Sie die Toleranz hinzu.
• Wenn Ihr Pod auf Knoten mit aktivierter GKE Sandbox ausgeführt werden muss, fügen Sie sowohl die Knotenaffinität als auch die Toleranz hinzu.

Das folgende Manifest ändert beispielsweise das unter Anwendung in einer Sandbox ausführen verwendete Manifest so, dass die Ausführung als regulärer Pod auf einem Knoten mit Pods erfolgt, die in einer Sandbox ausgeführt werden. Dafür wird die RuntimeClass entfernt und die beschriebene Markierung und Toleranz werden hinzugefügt:

# httpd-no-sandbox.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: httpd-no-sandbox
  labels:
    app: httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: httpd
  template:
    metadata:
      labels:
        app: httpd
    spec:
      containers:
      - name: httpd
        image: httpd
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: sandbox.gke.io/runtime
                operator: In
                values:
                - gvisor
      tolerations:
        - effect: NoSchedule
          key: sandbox.gke.io/runtime
          operator: Equal
          value: gvisor

Prüfen Sie zuerst, ob das Deployment in einer Sandbox ausgeführt wird:

kubectl get pods -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.runtimeClassName}\n{end}'

Die Ausgabe sieht etwa so aus:

httpd-db5899bc9-dk7lk: gvisor
httpd-no-sandbox-5bf87996c6-cfmmd:

Das zuvor erstellte httpd-Deployment wird in einer Sandbox ausgeführt, da seine RuntimeClass gvisor ist. Das httpd-no-sandbox-Deployment hat dagegen keinen Wert für RuntimeClass und wird somit nicht in einer Sandbox ausgeführt.

Prüfen Sie als Nächstes, ob das Deployment ohne Sandbox auf einem Knoten mit GKE Sandbox ausgeführt wird. Führen Sie dazu folgenden Befehl aus:

kubectl get pod -o jsonpath=$'{range .items[*]}{.metadata.name}: {.spec.nodeName}\n{end}'

Der Name des Knotenpools ist in den Wert von nodeName eingebettet. Prüfen Sie, ob der Pod auf einem Knoten in einem Knotenpool mit aktivierter GKE Sandbox ausgeführt wird.

Metadatenschutz prüfen

Durch Ausführen eines Tests können Sie validieren, dass Metadaten vor Knoten geschützt sind, die Pods in einer Sandbox ausführen können:

1. Erstellen Sie mithilfe von kubectl apply -f über das folgende Manifest ein Deployment, das in einer Sandbox ausgeführt wird. Dabei wird das fedora-Image verwendet, das den curl-Befehl enthält. Der Pod führt den Befehl /bin/sleep aus, damit das Deployment 10.000 Sekunden lang ausgeführt wird:

   # sandbox-metadata-test.yaml
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: fedora
     labels:
       app: fedora
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: fedora
     template:
       metadata:
         labels:
           app: fedora
       spec:
         runtimeClassName: gvisor
         containers:
         - name: fedora
           image: fedora
           command: ["/bin/sleep","10000"]
   

2. Rufen Sie den Namen des Pods mithilfe von kubectl get pods ab und verwenden Sie dann kubectl exec, um eine interaktive Verbindung zum Pod herzustellen:

   kubectl exec -it POD_NAME /bin/sh
   

   Sie sind in einer /bin/sh-Sitzung mit einem Container verbunden, der im Pod ausgeführt wird.

3. Versuchen Sie in der interaktiven Sitzung, auf eine URL zuzugreifen, die Clustermetadaten zurückgibt:

   curl -s "http://169.254.169.254/computeMetadata/v1/instance/attributes/kube-env" -H "Metadata-Flavor: Google"
   

   Der Befehl bleibt hängen und führt letztendlich zu einer Zeitüberschreitung, da die Pakete ohne Rückmeldung verworfen werden.

4. Drücken Sie Strg + C, um den curl-Befehl zu beenden, und geben Sie exit ein, um die Verbindung zum Pod zu trennen.

5. Entfernen Sie die Zeile RuntimeClass aus dem YAML-Manifest und stellen Sie den Pod mit kubectl apply -f FILENAME noch einmal bereit. Der in einer Sandbox ausgeführte Pod wird beendet und auf einem Knoten ohne GKE Sandbox neu erstellt.

6. Rufen Sie den Namen des neuen Pods ab, stellen Sie mithilfe von kubectl exec eine Verbindung zu ihm her und führen Sie den curl-Befehl noch einmal aus. Diesmal werden Ergebnisse zurückgegeben. Diese Beispielausgabe ist gekürzt:

   ALLOCATE_NODE_CIDRS: "true"
   API_SERVER_TEST_LOG_LEVEL: --v=3
   AUTOSCALER_ENV_VARS: kube_reserved=cpu=60m,memory=960Mi,ephemeral-storage=41Gi;...
   ...
   

   Geben Sie exit ein, um die Verbindung zum Pod zu trennen.

7. Entfernen Sie das Deployment:

   kubectl delete deployment fedora
   

GKE Sandbox deaktivieren

Sie können GKE Sandbox nicht in GKE Autopilot-Clustern oder GKE-Standardknotenpools deaktivieren. Wenn Sie GKE Sandbox nicht mehr verwenden möchten, löschen Sie den Knotenpool.

Nächste Schritte

• Mehr über das Verwalten von Knotenpools erfahren
• Überblick über die Sicherheit lesen