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 its trusted execution environment (TEE), the hardware boundary that protects the guest from its host. A verifier checks evidence against the expected node image and launch configuration; all workloads on that node share its hardware boundary. 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 CVMDeployment modes
The required c8s install --cvm-mode flag selects the deployment shape. The image-policy plugin uses the container runtime's Node Resource Interface (NRI) to check container admission.
| 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 | Google Kubernetes Engine confidential node; native TEE evidence | Chart-managed host NRI plugin |
aks | Azure Kubernetes Service confidential node; virtual Trusted Platform Module (vTPM) evidence from /dev/tpm0 | Chart-managed host NRI plugin |
The required --hardware-platform=sev-snp or tdx selects AMD SEV-SNP or Intel TDX independently of the deployment shape. On AKS, both use the vTPM evidence path. These settings select the local integration; the deployment still needs suitable confidential hardware and provider evidence support.
Separate trust inputs
The Certificate Distribution Service (CDS) runs in a separate confidential VM outside the cluster. The router is the public entry point that forwards requests to workloads. Three trust inputs serve different purposes:
| Trust input | What it establishes |
|---|---|
| CDS identity pin | The expected CDS VM image and exact launch configuration. --cds-pin accepts a pin-file path and loads its contents into the Helm value cds.measurementsConfig. Baked nodes obtain the pin from their measured launch file. |
| CDS node policy | The node images CDS accepts for certificate issuance, selected by measured configuration or signed commands as described below |
| Verifier's node or router policy | The expected target image and launch configuration, independently selected by the verifier; CDS-issued certificate claims also need a pinned mesh certificate authority (CA) |
CDS checks its configuration bytes against its own verified launch evidence before serving. That configuration includes operator public keys, workload policy, node image policy, inventory address ranges, and certificate naming policy. An empty node policy refuses certificate issuance.
A singleton, or single-replica CDS, uses the node policy from its measured configuration. In a high-availability (HA) deployment, the operator-signed Genesis command starts the replica group and selects its initial node policy. Genesis defaults to the configuration's node policy; its --nodes option can supply another set. Later signed commands can replace the live node policy.
For a current-policy check, the verifier supplies --served-policy-file with a JSON file containing the exact node policy they expect CDS to enforce. In HA, that expectation must reflect the most recent signed command that sets node policy. Verifying the CDS identity alone does not compare that policy. See the trust root and verification.
Enforcement inside the node
The node's kernel, kubelet, container runtime, and privileged node services are inside the CVM and form part of its trusted computing base. On managed services, the provider's control plane remains outside it. CDS verifies hardware evidence and admitted node identity before issuing certificates; node admission checks container launches against the allowlist.
On baked bare-metal nodes, the measured c8s-runc runtime wrapper enforces a minimum privilege policy for pod containers outside namespaces exempted by the measured policy. The runtime-created pod sandbox is also exempt. The controls include non-root execution, prevention of privilege escalation, private process namespaces, and bounded capabilities. The locked build of c8s-runc also refuses container exec. These guarantees depend on the admitted node image and its measured configuration. Chart-managed enforcement on GKE and AKS remains under the cluster administrator's control. See the image 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.