Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Auf vTPMs und Attestierungsdaten in Confidential GKE Nodes zugreifen

Standard

Die Arbeitslasten, die Sie auf Confidential Google Kubernetes Engine Nodes 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 für Sicherheitsingenieure beschrieben, wie sie vTPMs und hardwarebasierte Geräte für GKE-Arbeitslasten sichtbar machen, um Aufgaben wie Remote Attestation, Secret-Versiegelung und Erzeugung von Zufallszahlen auszuführen.

Sie sollten mit den folgenden Ressourcen vertraut sein:

Die spezifische Confidential Computing-Technologie, die Sie verwenden, hängt vom Bedrohungsmodell und den Sicherheitsanforderungen Ihres Unternehmens ab. Weitere Informationen finden Sie unter Confidential Computing-Technologien.

Confidential Computing-Aufgaben

Sie können von Pods aus auf vTPMs und Hardwaremodule zugreifen, die auf Confidential GKE Nodes ausgeführt werden. Mit diesen Modulen können Sie kryptografische Vorgänge wie die Secret-Versiegelung ausführen oder Remote Attestation durchführen. 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 Attestation: Arbeitslasten können eines der folgenden Module für Remote Attestation verwenden:
- AMD SEV: Das Shielded VM-vTPM.
- AMD SEV-SNP: Der hardwarebasierte AMD Secure Processor.
- Intel TDX: Das hardwarebasierte Intel TDX-Modul.
Weitere Informationen zur Funktionsweise der Remote Attestation 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, 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.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das Attribut compute/region fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

Aktivieren Sie Confidential GKE Nodes in einem Cluster oder Knotenpool, der alle Bedingungen im Abschnitt Voraussetzungen erfüllt. Weitere Informationen finden Sie unter Confidential GKE Nodes auf Clusterebene konfigurieren oder Confidential GKE Nodes auf Knotenpoolebene konfigurieren.

Voraussetzungen

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

Auf dem Cluster und den Knotenpools muss je nach dem Confidential Computing-Modul, auf das Sie zugreifen möchten, eine der folgenden Versionen ausgeführt werden:
- vTPMs: Beliebige GKE-Version.
- Hardwarebasierte AMD SEV-SNP-Gerä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 enthält. 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:

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 Steuerungsebene Ihres Clusters, z. B. us-central1 oder us-central1-a.

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, sind alle Confidential Computing-Geräte auf Ihren Confidential GKE Nodes für Pods sichtbar, die auf diesen Knoten ausgeführt werden.

Von Pods aus 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, ähnlich wie Sie andere erweiterte Ressourcen in Kubernetesanfordern. In den folgenden Abschnitten wird beschrieben, wie Sie von einem beliebigen Pod aus auf vTPMs und in AMD SEV-SNP- und Intel TDX-Knoten auf hardwarebasierte Module zugreifen.

Von Pods aus auf vTPMs zugreifen

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

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

Erstellen Sie den Pod:
```
kubectl apply -f example-vtpm-pod.yaml
```
Der Pod erhält Zugriff auf das Gerät /dev/tpmrm0.
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 die Versiegelung auszuführen. Wenn Sie AMD SEV verwenden, können Sie das vTPM auch verwenden, um die Remote Attestation der Confidential VM-Instanz durchzuführen.

Von Pods aus 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 Ressourcenlimits des Containers angeben. Sie müssen diese Module verwenden, um die Remote Attestation von Knoten durchzuführen, die AMD SEV-SNP und Intel TDX verwenden, da das vTPM nicht der Root of Trust für Messungen in diesen Technologien ist.

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

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

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

Erfahren Sie, wie Sie per Remote Attestation bestätigen, dass Arbeitslasten auf Confidential VM ausgeführt werden.

Auf vTPMs und Attestierungsdaten in Confidential GKE Nodes zugreifen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.