Confidential AI ･ Components and data flow: C8s

How the external CDS, confidential nodes, pod mesh, and public router work together.

C8s runs ordinary Kubernetes workloads inside confidential nodes. Each node is one attested confidential VM (CVM); its pods share that hardware trust boundary. The Certificate Distribution Service (CDS) runs in a separate confidential VM outside the cluster. It verifies node evidence and issues the certificates that authenticate pods to the mesh.

Components

Component	Role
CDS	Holds the mesh CA, verifies issuance requests, and serves workload policy, routes, and secrets
C8s operator and webhook	Reconcile workloads and inject pod mesh, certificate, and readiness containers, plus requested secret and volume helpers
attestation-api	Obtains node TEE evidence; baked into the `bare-metal` image or deployed by the chart on GKE and AKS
c8s-mesh	Injected endpoint in each covered pod that carries application TCP over TLS 1.3
nri-image-policy	Enforces image admission, maintains sandbox inventory, and installs and checks pod network rules
get-cert	Obtains and renews the pod's CDS-issued certificate for platform containers
get-secret and get-volume	Deliver authorized secrets and encrypted volumes to workloads
router	Public nginx front door with attestation, routing, and allowlist proxy services
volumed	Node agent that opens encrypted volumes for pods

The operator coordinates Kubernetes resources. CDS makes the certificate issuance decision from verified evidence and policy. Applications serve ordinary TCP or HTTP inside their pods; injected platform containers hold the private mesh credentials. The webhook rejects application mounts of that credential volume.

Deployment modes

c8s install requires a deployment mode (--cvm-mode=bare-metal, gke, or aks) and a CPU TEE (--hardware-platform=sev-snp or tdx). The self-managed bare-metal image includes the attestation API and NRI plugin. GKE and AKS use chart-managed services on the nodes. These modes describe the local integration; deployment still requires suitable confidential hardware and evidence support. All three use the node as one trust domain. See trust boundaries.

The cluster needs the external CDS endpoint and a pin for both its VM image and launch configuration. Baked nodes obtain these from their measured launch file; other installations supply them through chart values. CDS checks its configuration bytes against its own verified launch evidence before serving. That configuration establishes operator public keys, workload policy, inventory address ranges, and certificate naming policy. Its node-image policy controls node admission for CDS without HA and supplies the default node-image set for HA Genesis. See the trust root.

An optional measured HA configuration runs CDS as replicas sharing volatile CA, secret, allowlist, and sandbox-ledger state. An operator-signed Genesis command starts the CDS replica group, binding its initial mesh CA and approved CDS and node images. Genesis can select a node-image set that overrides the configuration default. Serving requires a valid leader-confirmed lease and locally applied state; quorum loss stops serving when that lease ceases to hold. Signed HA policy changes can update admitted node images after launch.

Certificate and traffic flow

Separate confidential VM
+-------------------------------------+
| CDS: attestation, CA, policy, secrets|
+-------------------------------------+
       ^ evidence + sandbox token
       | certificate returned to get-cert
       | CDS also queries node inventory
       v
Confidential Kubernetes node (one TEE boundary)
+--------------------------------------------------------+
| attestation-api       NRI admission + sandbox inventory |
|                                                        |
| Pod A                        Pod B                     |
| +-----------------+          +-----------------+       |
| | app <-> mesh    |<--TLS 1.3-->| mesh <-> app  |       |
| | get-cert        |          | get-cert        |       |
| +-----------------+          +-----------------+       |
+--------------------------------------------------------+

public client --HTTPS--> router --mesh TLS--> pod mesh --> app

The two pods may also run on different confidential nodes. Every pod in webhook scope receives mesh injection; confidential.ai/cw names workload and Service intent. NRI installs pod-local network rules and verifies them at admission and identity assertion. Captured application TCP passes through the mesh. DNS, health, and platform-role traffic have explicit exceptions. Operator-signed allowlist entries can also authorize direct TCP egress to specified IP ranges and ports; unsupported traffic is dropped.

For a sandbox-bound certificate, CDS verifies node evidence, a token signed by the node sandbox-inventory service, and the reported image digests against its allowlist. This service is supplied by nri-image-policy: it identifies the caller through local kernel peer credentials, and CDS authenticates it over attested TLS. A complete match to one allowlist entry additionally produces a workload-name and allowlist-digest stamp. The general /attest API also accepts requests without a sandbox token; those certificates lack sandbox identity and cannot authenticate to the pod mesh.

Mesh peers check the CDS-issued chain, certificate purpose and validity, mesh protocol, and sandbox identity. Hardware evidence is checked during issuance; the ordinary pod mesh applies no destination workload-name policy. See verification and the image allowlist.

The router applies the operator-signed route manifest it fetches from CDS. For a workload backend, it authenticates the pod's mesh endpoint and requires the route's allowlist workload name; a router whose certificate carries a workload stamp also requires the backend's allowlist digest to match its own. This workload name identifies a complete allowlist entry and is distinct from the cw Service identifier. An address backend instead uses the route's CA and server name for TLS authentication.

The router relays the allowlist API. Operators reach other CDS APIs, including /ca, /secrets, and /routes, through the verified external CDS endpoint, whose default port is 8443. Public clients use the router ingress configured for their deployment. See install.