Accedere ai vTPM e alle informazioni di attestazione nei Confidential GKE Node

I workload eseguiti sui nodi Confidential Google Kubernetes Engine possono accedere e utilizzare funzionalità di integrità e sicurezza della piattaforma come i moduli Virtual Trusted Platform (vTPM) e i report di attestazione di Confidential Computing. Questo documento mostra agli ingegneri della sicurezza come rendere visibili le vTPM e i dispositivi basati su hardware ai workload GKE per eseguire attività come l'attestazione remota, la sigillatura dei secret e la generazione di numeri casuali.

Dovresti già avere familiarità con le seguenti risorse:

La tecnologia Confidential Computing specifica che utilizzi dipende dal modello di minaccia e dai requisiti di sicurezza della tua organizzazione. Per ulteriori informazioni, consulta Tecnologie di confidential computing.

Attività di Confidential Computing

Puoi accedere a vTPM e moduli hardware dai pod in esecuzione su Confidential GKE Nodes. Puoi utilizzare questi moduli per eseguire operazioni crittografiche come la sigillatura dei secret o per l'attestazione remota. I moduli specifici utilizzati per queste attività dipendono dalla tecnologia Confidential Computing utilizzata dai nodi, come segue:

  • Sigillatura dei secret: in tutte le tecnologie di Confidential Computing, i workload possono utilizzare vTPM di Shielded VM come radice di attendibilità per la sigillatura dei secret.
  • Attestazione remota: i workload possono utilizzare uno dei seguenti moduli per l'attestazione remota:

    • AMD SEV: il vTPM di Shielded VM.
    • AMD SEV-SNP: il processore sicuro AMD basato su hardware.
    • Intel TDX: il modulo Intel TDX basato su hardware.

    Per saperne di più su come funziona l'attestazione remota in ciascuna di queste tecnologie di Confidential Computing, consulta Architettura e prove dell'attestatore.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Abilita l'API Google Kubernetes Engine.
  • Abilita l'API Google Kubernetes Engine
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Requisiti

Puoi utilizzare Confidential GKE Node alle seguenti condizioni:

  • Il cluster e i pool di nodi devono eseguire una delle seguenti versioni, a seconda del modulo Confidential Computing a cui vuoi accedere:

    • vTPMs: qualsiasi versione di GKE.
    • Dispositivi basati su hardware AMD SEV-SNP: GKE versione 1.33.5-gke.1350000 e successive o versione 1.34.1-gke.2037000 e successive.
    • Dispositivi basati su hardware Intel TDX: GKE versione 1.33.5-gke.1697000 e successive o versione 1.34.1-gke.2909000 e successive.
  • I pool di nodi devono trovarsi in una località di Compute Engine che disponga dei tipi di macchine corrispondenti. Per ulteriori informazioni sulla disponibilità regionale, vedi Tipi di macchina, CPU e zone.

  • I nodi devono utilizzare l'immagine del nodo Container-Optimized OS.

Installa il plug-in del dispositivo

Per rendere visibili le informazioni su integrità e sicurezza ai pod GKE, installa un plug-in del dispositivo. Per utilizzare un DaemonSet per installare il plug-in:

  1. Connettiti al cluster:

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

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster.
    • CONTROL_PLANE_LOCATION: la regione o la zona del control plane del cluster, ad esempio us-central1 o us-central1-a.
  2. Crea il DaemonSet cc-device-plugin:

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

Dopo aver creato il DaemonSet, tutti i dispositivi Confidential Computing sui tuoi Confidential GKE Nodes diventano visibili ai pod in esecuzione su questi nodi.

Accedere ai dispositivi Confidential Computing dai pod

Dopo aver creato il DaemonSet per installare il plug-in del dispositivo, puoi accedere a vTPM e dispositivi basati su hardware dai pod in modo simile a come richiedi altre risorse estese in Kubernetes. Le sezioni seguenti mostrano come accedere ai vTPM da qualsiasi pod e come accedere ai moduli basati su hardware nei nodi AMD SEV-SNP e Intel TDX.

Accedere ai vTPM dai pod

Per accedere alla vTPM di Shielded VM da qualsiasi pod in esecuzione su Confidential GKE Nodes, aggiungi il dispositivo google.com/cc ai limiti delle risorse del container. I passaggi riportati di seguito richiedono l'accesso a un vTPM in un pod di esempio:

  1. Salva il seguente manifest del pod come 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. Crea il pod:

    kubectl apply -f example-vtpm-pod.yaml
    

    Il Pod ottiene l'accesso al dispositivo /dev/tpmrm0.

  3. Per verificare che il pod possa accedere al vTPM, controlla i log del pod:

    kubectl logs my-vtpm-pod
    

    Se l'output contiene informazioni sui file, il pod può accedere al dispositivo.

Puoi interagire con il dispositivo dal codice dell'applicazione. Ad esempio, puoi utilizzare la libreria Go-TPM per comunicare con il vTPM ed eseguire attività come la sigillatura. Se utilizzi AMD SEV, puoi anche utilizzare vTPM per eseguire l'attestazione remota dell'istanza Confidential VM.

Accedere ai moduli basati su hardware dai pod

Se utilizzi AMD SEV-SNP o Intel TDX, puoi anche accedere ai moduli basati su hardware corrispondenti nei pod specificando il selettore corrispondente nei limiti delle risorse del container. Devi utilizzare questi moduli per eseguire l'attestazione remota dei nodi che utilizzano AMD SEV-SNP e Intel TDX, perché il vTPM non è la radice di attendibilità per le misurazioni in queste tecnologie.

I seguenti passaggi mostrano come richiedere l'accesso al processore sicuro AMD o al modulo Intel TDX:

  1. Salva uno dei seguenti pod di esempio:

    • Richiedi dispositivi AMD SEV-SNP:

      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

    • Richiedi dispositivi Intel TDX:

      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. Crea il pod:

    kubectl create -f PATH_TO_POD_MANIFEST
    

    Sostituisci PATH_TO_POD_MANIFEST con il percorso del file manifest del pod che hai salvato.

    I Pod ottengono l'accesso a uno dei seguenti dispositivi:

    • /dev/sev-guest per AMD SEV-SNP.
    • /dev/tdx_guest per Intel TDX.
  3. Per verificare che il pod possa accedere al dispositivo, controlla i log del pod:

    kubectl logs POD_NAME
    

    Sostituisci POD_NAME con il nome del pod di esempio che hai eseguito il deployment nel passaggio precedente.

    Se l'output contiene informazioni sui file, il pod può accedere al dispositivo.

Passaggi successivi