Run GKE Workloads on Confidential VMs for Data Security (2026)

Confidential VMs in GKE don’t actually encrypt data while it’s being processed by the CPU.

Let’s see this in action. Imagine you have a GKE cluster and you want to deploy a workload that needs to process sensitive data, but you want to ensure that even the cloud provider can’t see that data while it’s in memory. This is where Confidential GKE Nodes come in.

Here’s a basic deployment of a pod that could run on a Confidential GKE node. The critical part isn’t in the pod spec itself, but in the node pool configuration.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: confidential-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: confidential-app
  template:
    metadata:
      labels:
        app: confidential-app
    spec:
      containers:
      - name: app-container
        image: us-docker.pkg.dev/google-samples/containers/gke/counter:v1 # A simple example app
        ports:
        - containerPort: 8080

The magic happens when you create the node pool. You’d specify the machine type and then enable Confidential Computing.

gcloud container node-pools create confidential-pool \
  --cluster=my-gke-cluster \
  --machine-type=n2d-standard-4 \
  --confidential-nodes \
  --node-locations=us-central1-a \
  --num-nodes=1

The confidential-nodes flag is the key. This tells GKE to provision nodes using Confidential VM technology. When these nodes boot, they use hardware-based memory encryption (AMD SEV or Intel TDX). This means the data processed by the CPU, residing in RAM, is encrypted. The decryption and encryption keys are managed by the CPU itself and are not accessible to the host system or the cloud provider’s infrastructure.

When a pod is scheduled onto one of these Confidential GKE nodes, its memory is automatically encrypted. The operating system and the container runtime on the node do not have access to the plaintext data. This provides a strong isolation boundary, protecting your data from potential threats originating from the infrastructure layer. The application running inside the pod sees memory as usual, but the underlying hardware ensures that the actual contents of that memory are encrypted when not actively being used by the CPU.

What most people don’t realize is that Confidential GKE Nodes leverage hardware-based Trusted Execution Environments (TEEs). For AMD, this is Secure Encrypted Virtualization (SEV), and for Intel, it’s Trusted Domain Extensions (TDX). The VM’s memory is encrypted by the CPU, and the keys are managed by the CPU’s security processor. This means the hypervisor and the host OS cannot decrypt the VM’s memory. You can even verify the integrity and attestation of the environment before your workload starts, ensuring it’s running on genuine confidential hardware and hasn’t been tampered with.

Once you have your confidential node pool set up, you might want to explore how to control which workloads run on these nodes using node selectors and taints/tolerations.