Skip to content

Confidential Computing Prerequisites

Summary

CloudTaser provides cryptographic guarantees against hypervisor-level memory access only when running on AMD SEV-SNP or Intel TDX confidential compute nodes. On standard VMs, CloudTaser provides comprehensive defense-in-depth against software-level access -- including all Kubernetes control plane compromise scenarios -- but does not protect against direct hypervisor memory inspection.

This page explains the distinction, lists the recommended compute SKUs, and describes how to verify your deployment.

What standard VMs protect against

On standard (non-confidential) VMs, CloudTaser's three defense layers -- wrapper (memfd_secret), eBPF enforcement, and EU-hosted secret store -- protect against:

Threat Protection mechanism
Kubernetes control plane compromise (etcd access, API server compromise) Secrets never touch etcd, K8s Secrets, or disk
Node-level root access (ptrace, /proc/PID/mem, process_vm_readv) eBPF LSM blocks these syscalls; memfd_secret removes pages from kernel direct map
Kernel module attacks (LKM rootkits) memfd_secret pages are not in the kernel direct map
/dev/mem, /dev/kmem, kdump memfd_secret + eBPF enforcement
Swap-to-disk leakage mlock(2) pins pages in RAM
Core dumps MADV_DONTDUMP + PR_SET_DUMPABLE(0)

This covers the vast majority of real-world attack scenarios.

What requires confidential compute

One attack path remains on standard VMs: hypervisor-level memory access.

The hypervisor operates below the kernel. A cloud provider -- whether compelled by law (CLOUD Act, FISA 702) or through an insider compromise -- can take a live VM memory snapshot. This is a standard cloud operation used for migrations and debugging. The snapshot captures all physical memory pages backing the VM, including:

  • memfd_secret-backed buffers (these are removed from the kernel direct map, but the hypervisor reads physical memory directly)
  • All other process memory (Go heap, stack, TLS session keys)

MADV_DONTDUMP, RLIMIT_CORE, and eBPF LSM enforcement all operate at or above the kernel and provide no protection against a hypervisor-level read.

This is the only known path by which a cloud provider can access secret values without touching the EU secret store.

The fix: confidential compute VMs

AMD SEV-SNP and Intel TDX encrypt guest VM memory with per-VM keys that the hypervisor does not hold. A hypervisor memory read returns ciphertext. This closes the last remaining access path.

Provider SKU family Technology Status
GCP n2d-standard-* (Confidential VM) AMD SEV-SNP Generally Available
Azure DCdsv5 / ECdsv5 Intel TDX Generally Available
Azure DCasv5 / ECasv5 AMD SEV-SNP Generally Available
AWS Nitro-based Confidential VMs AMD SEV-SNP Preview

For managed Kubernetes:

  • GKE: Enable Confidential Nodes on the node pool. Node label: cloud.google.com/gke-confidential-nodes=true
  • AKS: Use DCdsv5/DCasv5 VM sizes. Node label varies by SKU
  • EKS: Confidential nodes are not yet generally available

Verification

Check node labels

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.cloud\.google\.com/gke-confidential-nodes}{"\n"}{end}'

A value of true confirms SEV-SNP is active on GKE nodes.

AMD SEV attestation (GKE)

On GKE Confidential Nodes, the sevguest device is available:

ls /dev/sev-guest  # present on SEV-SNP nodes

Remote attestation via AMD's SEV Attestation API can cryptographically verify the node is running inside a genuine confidential VM.

Important nuance: managed K8s + confidential compute

SEV-SNP/TDX proves environment sovereignty -- a genuine confidential VM is running with a measured kernel, and the hypervisor cannot read its memory.

It does not prove workload-identity sovereignty on managed Kubernetes. The cloud provider controls the K8s control plane and can issue ServiceAccount JWTs for arbitrary workloads. True per-pod isolation requires Confidential Containers (CoCo) running inside confidential VMs.

CloudTaser's wrapper + eBPF enforcement addresses the workload-identity gap at the software level: even with a forged SA JWT, the attacker cannot read secret pages from another pod's memfd_secret regions without triggering eBPF enforcement. The combination of CC substrate + CloudTaser provides the strongest posture.

Decision framework

Use the Sovereign Deployment Decision Guide for the full decision tree. In short:

  • Standard VM + CloudTaser: Protection against all software-level threats. Sufficient for most regulated workloads where the threat model excludes direct provider compulsion.
  • Confidential VM + CloudTaser: Protection against both software-level and hypervisor-level threats. Required when the threat model includes a compelled or compromised cloud provider.
  • Confidential VM + CloudTaser + CoCo: Maximum posture. Per-pod confidential VMs with CloudTaser's eBPF enforcement inside. Required when per-pod isolation is needed on a shared cluster.

See also