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 inside hardware-backed Trusted Execution Environments (TEEs) from the moment they enter the cluster until they leave it: encrypted in CVM memory, hardware-isolated on the GPU, and that protection 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.

Where to go next

The one decision to make before anything else is the deployment shape — each pod as its own confidential VM, or the whole node as one. It sets the trust boundary and it is not something you flip later. See trust boundaries.