Skip to content

Confidential Computing Prerequisites

Summary

Hypervisor resistance requires independently qualified confidential compute, attestation and key-release policy, for example on AMD SEV-SNP or Intel TDX. CloudTaser software alone does not establish that boundary. On standard VMs, covered runtime read-path controls depend on identity, application and guest-kernel trust and do not prevent direct hypervisor memory inspection. Raw store login and copied/encoded-secret disclosure remain separate limits even with confidential compute.

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

Standard VMs retain hypervisor-level memory access, in addition to the identity, application and guest-kernel limits above.

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.

Confidential compute does not qualify node protection

AKS requires a verified node configuration. Assessed stock Ubuntu and Azure Linux defaults omit bpf and are expected to refuse (assessed, not run). Actual enforcement/refusal needs live evidence. A confidential VM size or secret-memory capability does not establish readiness. See Platform Compatibility.

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.

Covered process-memory reads and raw store authentication are separate paths. In direct mode, a valid JWT for the permitted ServiceAccount/namespace can obtain the role's allowed records without reading another process. Node root can steal that JWT. Use one workload per identity and restrict workload creation; confidential compute does not bind direct store release to the wrapper. One workload per identity also applies on Port. Denial of a second same-identity workload on Port has not been established; a different-ServiceAccount reader test is not that evidence. This limit remains unresolved; see Security Model.

Decision framework

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

  • Standard VM + CloudTaser: Covered software read-path controls, subject to identity, application and guest-kernel trust. External hypervisor access remains outside the boundary.
  • Confidential VM + CloudTaser: Adds the qualified external hypervisor boundary; raw direct login, arbitrary guest-kernel code and authorised application disclosure remain limits.
  • Confidential VM + CloudTaser + CoCo: A separate deployment design requiring qualification; availability of per-pod confidential VMs does not prove CloudTaser node-agent compatibility or close direct store-login paths.

See also