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

I workload che esegui sui Confidential Google Kubernetes Engine Node possono accedere e utilizzare le 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 i 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à conoscere le seguenti risorse:

La tecnologia Confidential Computing specifica che utilizzi dipende dal modello di minaccia e dai requisiti di sicurezza della tua organizzazione. Per saperne di più, consulta Tecnologie di Confidential Computing.

Attività di Confidential Computing

Puoi accedere ai vTPM e ai moduli hardware dai pod in esecuzione sui Confidential GKE Node. Puoi utilizzare questi moduli per eseguire operazioni di crittografia 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 Confidential Computing, i workload possono utilizzare il 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ù sul funzionamento dell'attestazione remota in ciascuna di queste tecnologie Confidential Computing, consulta Architettura e prove dell'attestatore.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
  • Abilita l'API Google Kubernetes Engine
  • Se vuoi 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 gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Requisiti

Puoi utilizzare i Confidential GKE Node alle seguenti condizioni:

  • Il cluster e i node pool 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 versioni successive o versione 1.34.1-gke.2037000 e versioni successive.
    • Dispositivi basati su hardware Intel TDX: GKE versione 1.33.5-gke.1697000 e versioni successive o versione 1.34.1-gke.2909000 e versioni successive.
  • I node pool devono trovarsi in una località Compute Engine che dispone dei tipi di macchine corrispondenti. Per saperne di più sulla disponibilità regionale , consulta Tipi di macchine, CPU e zone.

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

Installare il plug-in del dispositivo

Per rendere visibili le informazioni sull'integrità e la 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 piano di controllo 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 Confidential GKE Node 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 ai vTPM e ai 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 al vTPM di Shielded VM da qualsiasi pod in esecuzione sui Confidential GKE Node, aggiungi il dispositivo google.com/cc ai limiti delle risorse del container. I seguenti passaggi 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 il vTPM per eseguire l'attestazione remota dell'istanza di 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 di cui hai eseguito il deployment nel passaggio precedente.

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

Passaggi successivi