Node trust boundary
How c8s protects and attests a confidential Kubernetes node, and how the deployment modes differ.
c8s treats the Kubernetes node as one confidential VM (CVM). Workload pods run as ordinary containers inside it. A verifier checks the node's launch measurement; all workloads on that node share its TEE boundary and measurement. Use separate nodes for tenants that do not trust each other.
L0: cloud or bare-metal host and hypervisor — outside the trust boundary
L1: confidential Kubernetes node — the attested unit
L2: ordinary workload containers — protected by the node CVMChoose the deployment shape with the required --cvm-mode flag:
| Mode | Node image and evidence | Image admission |
|---|---|---|
bare-metal | Self-managed confidential node image; native /dev/sev-guest or /dev/tdx-guest evidence | Fail-closed NRI plugin baked into the node image |
gke | GKE confidential node; native TEE evidence | Chart-managed host NRI plugin |
aks | AKS confidential node; Azure vTPM evidence from /dev/tpm0 | Chart-managed host NRI plugin |
--hardware-platform=sev-snp or tdx selects the CPU TEE independently of the deployment shape. On AKS, both attest through the vTPM. The --measurements flag pins the expected node launch measurement into CDS and the RA-TLS mesh.
The node's kubelet and container runtime are inside the CVM. On managed services, the provider's control plane remains outside it. c8s does not treat an API-server assertion as attestation: CDS verifies hardware evidence before issuing certificates, and the node admission policy checks container images against the allowlist.
The node is a single trust domain. A pod is protected from the host outside the CVM, but it does not have a separate hardware boundary from other pods or node services. See the architecture and the threat model.