Overview

c8s (Confidential Kubernetes) makes any Kubernetes cluster confidential. You have a cluster, you want it confidential — c8s is the switch. Your workloads' data and artifacts — model weights, prompts, responses, datasets, and credentials — stay encrypted in hardware-backed Trusted Execution Environment (TEE) memory from the moment they enter the cluster until they leave it, and that property is cryptographically provable to any independent third party.

Private inference, training and fine-tuning, agents, or any existing Kubernetes workload can inherit that guarantee with minimal changes — c8s keeps the Kubernetes surface you already use.

The design assumption is simple and uncompromising: the host is adversarial. The cloud provider, the bare-metal operator, and anything that can read raw host memory or inspect a QEMU command line are all outside the trust boundary. "It works on a normal cluster" is not the bar. It must work on a confidential one, with the threat model intact.

Why Confidential Kubernetes

Running workloads on someone else's infrastructure creates a three-sided trust problem, and contractual promises do not solve any side of it:

• Artifact owners — model weights, datasets, proprietary code — risk exfiltration the moment their artifacts touch third-party infrastructure.
• Compute providers want to host valuable workloads without being able (or liable) to observe them.
• End users in healthcare, legal, financial, and national-security settings need a hard guarantee that their inputs and outputs stay opaque to the operator.

Hardware TEEs (AMD SEV-SNP, Intel TDX, and NVIDIA Confidential Computing) resolve all three at once: they encrypt the runtime in hardware, measure the code that booted, and let that measurement be attested to a remote verifier. c8s turns those primitives into a working Kubernetes platform — even on managed services like GKE and AKS where the control plane itself cannot be attested.

Read the full design in the c8s whitepaper (arXiv).

The five principles

c8s applies the same five principles end-to-end:

1. Encrypt the runtime — workloads run in hardware-encrypted memory the host cannot read.
2. Measure the code — the hardware computes a launch digest over exactly what booted.
3. Bind identity to measurement — credentials are issued only after the measurement is verified, so a certificate is proof of what is running.
4. Verify before connecting — peers require an attestation-rooted identity before traffic flows.
5. Secure the egress — all traffic is encrypted to verified destinations.

How the pieces fit

                                              UNTRUSTED HOST
 ╔══ TEE BOUNDARY · HOST CANNOT READ ═════════╗
 ║                                            ║
 ║  ┌─────────────┐  challenge  ┌───────────┐ ║ inject ┌──────────────────┐
 ║  │     CDS     │◄─── + CSR ──┤ Workload  │◄╫────────┤   c8s operator   │
 ║  │             │             │    pod    │ ║        │  webhook · CRDs  │
 ║  │ evidence ·  ├── leaf ────►│           │ ║        └──────────────────┘
 ║  │ sign CSR ·  │    cert     │ + get-cert│ ║
 ║  │ mesh CA     │             │  sidecar  │◄╫──┐     ┌──────────────────┐
 ║  └──────┬──────┘             └─────┬─────┘ ║  │     │ nri-image-policy │
 ║         │ verify            RA-TLS │       ║  └─────┤ digest allowlist │
 ║         ▼                          ▼       ║ enforce└──────────────────┘
 ║  ┌─────────────┐             ┌───────────┐ ║
 ║  │attestation- │             │ ratls-mesh│ ║
 ║  │    api      │             │           │ ║
 ║  │SEV-SNP /TDX │             │ RA-TLS L4 │ ║
 ║  │  verifier   │             │   proxy   │ ║
 ║  └─────────────┘             └───────────┘ ║
 ║                                            ║
 ╚════════════════════════════════════════════╝

One term you will see throughout: RA-TLS (Remote-Attestation TLS) — mTLS where each certificate carries hardware attestation evidence, so a peer verifies both identity and that the peer runs in a genuine TEE at an expected measurement.

Two deployment shapes

c8s supports two trust boundaries; the choice is the most important architectural decision you will make:

Your path through the docs