Auf vTPMs und Attestierungsdaten in Confidential GKE Nodes zugreifen

Die Arbeitslasten, die Sie auf Confidential Google Kubernetes Engine-Knoten ausführen, können auf Plattformintegritäts- und Sicherheitsfunktionen wie Virtual Trusted Platform Modules (vTPMs) und Confidential Computing-Attestierungsberichte zugreifen und diese verwenden. In diesem Dokument wird beschrieben, wie Sicherheitsingenieure vTPMs und hardwarebasierte Geräte für GKE-Arbeitslasten sichtbar machen können, um Aufgaben wie Remote Attestation, Secret-Versiegelung und Erzeugung von Zufallszahlen auszuführen.

Sie sollten bereits mit den folgenden Ressourcen vertraut sein:

Welche Technologie für Confidential Computing Sie verwenden, hängt vom Bedrohungsmodell und den Sicherheitsanforderungen Ihrer Organisation ab. Weitere Informationen finden Sie unter Confidential Computing-Technologien.

Confidential Computing-Aufgaben

Sie können über Pods, die auf Confidential GKE Nodes ausgeführt werden, auf vTPMs und Hardwaremodule zugreifen. Sie können diese Module für kryptografische Vorgänge wie das Versiegeln von Secrets oder für die Remote-Attestierung verwenden. Die für diese Aufgaben verwendeten Module hängen von der Confidential Computing-Technologie ab, die von den Knoten verwendet wird:

  • Secret-Versiegelung: Bei allen Confidential Computing-Technologien können Arbeitslasten das Shielded VM-vTPM als Root of Trust für die Secret-Versiegelung verwenden.

  • Remote-Attestierung: Arbeitslasten können eines der folgenden Module für die Remote-Attestierung verwenden:

    • AMD SEV: Das vTPM der Shielded VM.
    • AMD SEV-SNP: der hardwarebasierte AMD Secure Processor.
    • Intel TDX: Das hardwarebasierte Intel TDX-Modul.

    Weitere Informationen zur Funktionsweise der Remote-Attestierung in den einzelnen Confidential Computing-Technologien finden Sie unter Attester-Architektur und ‑Nachweis.

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 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 dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

Voraussetzungen

Sie können Confidential GKE Nodes unter den folgenden Bedingungen verwenden:

  • Auf dem Cluster und den Knotenpools muss eine der folgenden Versionen ausgeführt werden, je nachdem, auf welches Confidential Computing-Modul Sie zugreifen möchten:

    • vTPMs: Beliebige GKE-Version.
    • AMD SEV-SNP-Hardwaregeräte: GKE-Version 1.33.5-gke.1350000 und höher oder Version 1.34.1-gke.2037000 und höher.
    • Hardwarebasierte Intel TDX-Geräte: GKE-Version 1.33.5-gke.1697000 und höher oder Version 1.34.1-gke.2909000 und höher.

  • Die Knotenpools müssen sich an einem Compute Engine-Standort befinden, der die entsprechenden Maschinentypen hat. Weitere Informationen zur regionalen Verfügbarkeit finden Sie unter Maschinentypen, CPUs und Zonen.

  • Die Knoten müssen das Knoten-Image für Container-Optimized OS verwenden.

Geräte-Plug-in installieren

Damit Integritäts- und Sicherheitsinformationen für GKE-Pods sichtbar sind, installieren Sie ein Geräte-Plug-in. So installieren Sie das Plug-in mit einem DaemonSet:

  1. Stellen Sie eine Verbindung zu Ihrem Cluster her:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • CONTROL_PLANE_LOCATION: die Region oder Zone der Cluster-Steuerungsebene, z. B. us-central1 oder us-central1-a.

  2. Erstellen Sie das DaemonSet cc-device-plugin:

    kubectl create -f https://raw.githubusercontent.com/google/cc-device-plugin/main/manifests/cc-device-plugin.yaml

Nachdem Sie das DaemonSet erstellt haben, werden alle Confidential Computing-Geräte auf Ihren Confidential GKE Nodes für Pods sichtbar, die auf diesen Knoten ausgeführt werden.

Über Pods auf Confidential Computing-Geräte zugreifen

Nachdem Sie das DaemonSet zum Installieren des Geräte-Plug-ins erstellt haben, können Sie von Pods aus auf vTPMs und hardwarebasierte Geräte zugreifen. Das funktioniert ähnlich wie beim Anfordern anderer erweiterter Ressourcen in Kubernetes. In den folgenden Abschnitten wird beschrieben, wie Sie von einem beliebigen Pod aus auf vTPMs und auf hardwarebasierte Module in AMD SEV-SNP- und Intel TDX-Knoten zugreifen.

Über Pods auf vTPMs zugreifen

Wenn Sie von einem beliebigen Pod, der auf Confidential GKE Nodes ausgeführt wird, auf das vTPM der Shielded VM zugreifen möchten, fügen Sie das Gerät google.com/cc den Containerressourcenlimits hinzu. Mit den folgenden Schritten wird der Zugriff auf ein vTPM in einem Beispiel-Pod angefordert:

  1. Speichern Sie das folgende Pod-Manifest als example-vtpm-pod.yaml:

    apiVersion: v1
kind: Pod
metadata:
name: my-vtpm-pod
spec:
containers:
- name: test-vtpm
  image: ubuntu
  command: ["/bin/sh", "-c", "ls -l /dev/tpmrm0; sleep 3600"]
  ports:
  - containerPort: 8080
    name: http
  resources:
    limits:
      google.com/cc: 1

  2. Erstellen Sie den Pod:

    kubectl apply -f example-vtpm-pod.yaml

    Der Pod erhält Zugriff auf das Gerät /dev/tpmrm0.

  3. Prüfen Sie die Pod-Logs, um zu bestätigen, dass der Pod auf das vTPM zugreifen kann:

    kubectl logs my-vtpm-pod

    Wenn die Ausgabe Dateiinformationen enthält, kann der Pod auf das Gerät zugreifen.

Sie können über Ihren Anwendungscode mit dem Gerät interagieren. Sie können beispielsweise die Go-TPM-Bibliothek verwenden, um mit dem vTPM zu kommunizieren und Aufgaben wie das Versiegeln auszuführen. Wenn Sie AMD SEV verwenden, können Sie das vTPM auch für die Remote-Attestierung der Confidential VM-Instanz verwenden.

Über Pods auf hardwarebasierte Module zugreifen

Wenn Sie AMD SEV-SNP oder Intel TDX verwenden, können Sie auch auf die entsprechenden hardwarebasierten Module in Pods zugreifen, indem Sie den entsprechenden Selektor in den Containerressourcenlimits angeben. Sie müssen diese Module verwenden, um Knoten, die AMD SEV-SNP und Intel TDX verwenden, per Remote-Attestierung zu prüfen, da das vTPM bei diesen Technologien nicht die Root of Trust für Messungen ist.

In den folgenden Schritten erfahren Sie, wie Sie Zugriff auf den AMD Secure Processor oder das Intel TDX-Modul anfordern:

  1. Speichern Sie einen der folgenden Beispiel-Pods:

    • AMD SEV-SNP-Geräte anfordern:

      apiVersion: v1
kind: Pod
metadata:
  name: snp-test-pod
spec:
  containers:
  - name: test-container
    image: alpine
    command: ["/bin/sh", "-c"]
    args:
      - |
        echo "Checking for SEV-SNP device..."
        ls -l /dev/sev-guest
        echo "SNP container started successfully"
        sleep 3600
    resources:
      limits:
        amd.com/sev-snp: "1"
      requests:
        amd.com/sev-snp: "1"
  nodeSelector:
    cloud.google.com/gke-confidential-nodes-instance-type: SEV_SNP

    • Intel TDX-Geräte anfordern:

      apiVersion: v1
kind: Pod
metadata:
  name: tdx-test-pod
spec:
  containers:
  - name: test-container
    image: alpine
    command: ["/bin/sh", "-c"]
    args:
      - |
        echo "Checking for TDX device..."
        ls -l /dev/tdx*
        echo "TDX container started successfully"
        sleep 3600
    resources:
      limits:
        intel.com/tdx: "1"
      requests:
        intel.com/tdx: "1"
  nodeSelector:
    cloud.google.com/gke-confidential-nodes-instance-type: TDX

  2. Erstellen Sie den Pod:

    kubectl create -f PATH_TO_POD_MANIFEST

    Ersetzen Sie PATH_TO_POD_MANIFEST durch den Pfad zur gespeicherten Pod-Manifestdatei.

    Die Pods erhalten Zugriff auf eines der folgenden Geräte:

    • /dev/sev-guest für AMD SEV-SNP.
    • /dev/tdx_guest für Intel TDX.

  3. Prüfen Sie die Pod-Logs, um zu bestätigen, dass der Pod auf das Gerät zugreifen kann:

    kubectl logs POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des Beispiel-Pods, den Sie im vorherigen Schritt bereitgestellt haben.

    Wenn die Ausgabe Dateiinformationen enthält, kann der Pod auf das Gerät zugreifen.

Nächste Schritte