Access vTPMs and attestation information in Confidential GKE Nodes

The workloads that you run on Confidential Google Kubernetes Engine Nodes can access and use platform integrity and security features such as Virtual Trusted Platform Modules (vTPMs) and Confidential Computing attestation reports. This document shows Security engineers how to make vTPMs and hardware-based devices visible to GKE workloads to perform tasks like remote attestation, secret sealing, and random number generation.

You should already be familiar with the following resources:

The specific Confidential Computing technology that you use depends on your organization's threat model and security requirements. For more information, see Attester architecture and evidence.

Limitations

You can make vTPMs visible to GKE applications only in Confidential GKE Nodes that use AMD SEV. If you use AMD SEV-SNP or Intel TDX, then you can't access vTPMs from the workloads.

Before you begin

Before you start, make sure that you have performed the following tasks:

  • Enable the Google Kubernetes Engine API.
    • Enable Google Kubernetes Engine API
  • To use the Google Cloud CLI for this task, install and then initialize the gcloud CLI. If you previously installed the gcloud CLI, get the latest version by running the gcloud components update command. Earlier gcloud CLI versions might not support running the commands in this document.

Requirements

You can use Confidential GKE Nodes under the following conditions:

  • The cluster and node pools must run one of the following versions, depending on the Confidential Computing features that you want to use:

    • vTPMs and AMD SEV: any GKE version.
    • AMD SEV-SNP hardware-based devices: GKE version 1.33.5-gke.1350000 and later or version 1.34.1-gke.2037000 and later.
    • Intel TDX hardware-based devices: GKE version 1.33.5-gke.1697000 and later or version 1.34.1-gke.2909000 and later.

  • The node pools must be in a Compute Engine location that has the corresponding machine types. For more information about regional availability, see Machine types, CPUs, and zones.

  • The nodes must use the Container-Optimized OS node image.

Install the device plugin

To make integrity and security information visible to GKE Pods, you install a device plugin. To use a DaemonSet to install the plugin, follow these steps:

  1. Connect to your cluster:

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

    Replace the following:

    • CLUSTER_NAME: the name of your cluster.
    • CONTROL_PLANE_LOCATION: the region or zone of your cluster control plane, such as us-central1 or us-central1-a.

  2. Create the cc-device-plugin DaemonSet:

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

After you create the DaemonSet, any Confidential Computing devices on your Confidential GKE Nodes become visible to Pods that run on those nodes.

Configure Pods to use the devices

You can request any available devices, such as vTPMs or hardware-based guest VMs, by specifying the corresponding selector in the resources.limits field of a Pod specification. This method of requesting devices is similar to how you request other extended resources in Kubernetes.

The following steps show you how to request various devices in Pods:

  1. Save one of the following example Pods:

    • Request vTPMs on AMD SEV nodes:

      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

    • Request AMD SEV-SNP devices:

      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

    • Request Intel TDX devices:

      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. Create the Pod:

    kubectl create -f PATH_TO_POD_MANIFEST

    Replace PATH_TO_POD_MANIFEST with the path to the Pod manifest file that you saved.

    The Pods get access to one of the following devices:

    • /dev/tpmrm0 for vTPMs.
    • /dev/sev-guest for AMD SEV-SNP.
    • /dev/tdx_guest for Intel TDX.

  3. To verify that the Pod can access the device, check the Pod logs:

    kubectl logs POD_NAME

    Replace POD_NAME with the name of the example Pod that you deployed in the previous step.

    If the output contains file information, then the Pod can access the device.

What's next