Overview

c8s is Confidential Kubernetes for confidential computing at data centre scale. It uses Kubernetes to orchestrate pods across confidential workers.

Each worker is a confidential VM (CVM) protected by a hardware Trusted Execution Environment (TEE), using Intel TDX or AMD SEV-SNP.

Threat model

The physical host, hypervisor, and Kubernetes control plane sit outside the trust boundary. The TEE isolates execution and encrypts guest memory to protect data in use against host inspection and tampering.

Your control plane schedules pods, but the measured worker checks images and launch constraints against operator-approved policy. Your normal admin kubeconfig manages Kubernetes objects.

A worker is one trust domain: its pods share a guest kernel, container runtime, and TEE.

• Put tenants that do not trust each other on separate workers.
• A guest kernel compromise can expose that worker's data.
• Attestation proves a measured boot identity; it does not prove the software has no vulnerabilities.

Policy and connections

The Certificate Distribution Service (CDS) is the policy engine. It runs separately in its own confidential VMs and:

• Holds operator-approved policy that workers retrieve and enforce locally.
• Verifies worker evidence and workload admission before issuing mesh identities or releasing authorized secrets.
• Shares the cluster's CA, policy, and secrets across three replicas, keeping service available through one replica loss.

Applications use ordinary TCP or HTTP inside their pods. The injected mesh protects application TCP between admitted workloads; DNS, health checks, and explicitly allowed direct traffic have separate rules.

Clients verify the expected image, launch configuration, and workload policy before sending data.

Set up a deployment

Follow these tasks in order. The examples use TDX and three CDS replicas.

1. Prepare launch inputs: select artifacts, create operator keys, and prepare the CDS and worker documents.
2. Start policy enforcement: boot independent replicas, admit the first worker, and verify the quorum.
3. Start a worker: join your external Kubernetes API and check node readiness.
4. Run a workload: approve its launch constraints, deploy it, and test ingress.
5. Verify a connection: enforce approved image, launch, policy, and route pins before sending private data.
6. Operations and FAQ: keep replicas available, roll updates, and understand security limits.