---
title: 'C8s: Confidential Kubernetes'
url: https://www.emergentmind.com/topics/c8s
type: topic
---

# C8s: Confidential Kubernetes

Searching arXiv for the exact C8s paper and closely related confidential Kubernetes / TEE work to ground the article.
Search query: "ti:\"C8s\" OR all:\"Confidential Kubernetes\""

C8s, short for “Confidential Kubernetes,” is a confidential computing architecture and reference platform for Kubernetes that provides cryptographically rooted confidentiality, integrity, and verifiability guarantees for Kubernetes clusters from infrastructure operators. It is built on hardware Trusted Execution Environments (TEEs), specifically AMD SEV-SNP, Intel TDX, and NVIDIA Confidential Computing support, and establishes an attestation-rooted trust boundary around confidential VMs. A defining property of the design is compatibility with both self-hosted and managed Kubernetes services such as Amazon EKS, Google GKE, and Microsoft AKS, even where the control plane cannot be attested. Within that boundary, C8s is intended to protect plaintext workloads, data, and secrets from the cloud provider, hypervisor, host OS, and Kubernetes administrators, while making the resulting guarantees cryptographically provable to an independent verifier [2604.26974].

## 1. Design objectives and architectural scope

C8s is organized around three explicit protection targets: workload inputs and outputs, sensitive artifacts, and intermediate state. The examples given for these classes are LLM queries and patient records as workload inputs and outputs, model weights, datasets, and keys as sensitive artifacts, and activations and caches as intermediate state. The architecture aims to guarantee confidentiality, integrity, and verifiability by default while minimizing changes to existing Kubernetes surfaces, so that developers write pods as usual [2604.26974].

Its stated scope includes the trust model, threat model, attestation and certificate-issuance flows, client protocols, node-level versus pod-level trust boundaries, and integration patterns. It explicitly excludes a deep dive on the build system Kettle, as well as side-channel and physical attacks. This scoping is significant because it defines C8s not as a general secure-computing theory for Kubernetes, but as a concrete deployment architecture centered on attested execution, identity issuance, and protected communications in realistic cloud environments [2604.26974].

The architecture also addresses what the source describes as a three-sided trust problem. Under conventional arrangements, artifact owners, compute providers, and end users must rely on contractual controls. C8s instead places the trust anchor in attested hardware execution. Data and artifact owners can deploy sensitive workloads and proprietary artifacts on third-party infrastructure without risking exfiltration; compute providers can offer execution services without revealing workloads to cloud operators; and end users can submit requests that remain opaque to all parties except the attested TEE processing them [2604.26974].

## 2. Trust model and adversarial assumptions

The trust model separates hardware-rooted and attested components from the rest of the Kubernetes and cloud stack. Hardware manufacturers, TEE hardware and firmware, code measured inside the TEE, and the attested CDS are placed inside the effective trust boundary, whereas the cloud provider, hypervisor, host OS, BIOS, device drivers, Kubernetes control plane, storage backends, network infrastructure, privileged operators, and the physical host are treated as untrusted [2604.26974].

| Trusted (inside boundary) | Untrusted (outside) |
|---|---|
| Hardware manufacturer; TEE hardware and firmware | Cloud provider; hypervisor |
| Code measured inside TEE; CDS | Host OS; BIOS; device drivers |
|  | Kubernetes control plane; storage; network infrastructure; privileged operators; physical host |

Within this model, the adversary is assumed to have full control of the hypervisor, host OS, Kubernetes API, and related software surfaces, as well as the ability to capture memory, intercept network traffic, and inspect disk. The attacks addressed therefore include memory snooping and tampering, code substitution, “man-in-the-middle” internal traffic, unauthorized container injection, and key exfiltration. The mechanisms corresponding to these are, respectively, TEE memory encryption and integrity protection, attestation-based measurement binding, the raTLS mesh, NRI or in-pod measured policy, and CDS-mediated secret release into TEE memory only [2604.26974].

The paper is equally explicit about what C8s does not claim to solve. Microarchitectural side channels, physical attacks, denial-of-service, and application-layer logic flaws or inference attacks remain out of scope. One physical-security assumption is singled out: the datacenter operator will not perform physical memory-bus probing, DIMM tampering, or JTAG attacks. A common misconception is therefore that C8s makes the entire Kubernetes environment trusted; the text instead defines a narrower hardware-enforced trust boundary and leaves major operational and application-level attack classes outside it [2604.26974].

## 3. TEE foundations and attestation semantics

All guarantees in C8s are derived from standard TEE primitives. Confidentiality is provided because all guest memory, including DRAM and VRAM with NVIDIA Confidential Computing, is hardware-encrypted and cannot be decrypted by the hypervisor, DMA devices, or host OS. Integrity is provided by hardware detection of replay, remapping, and corruption attempts. Verifiability arises from a cryptographic measurement computed at launch, described as $H(\text{code} \parallel \text{firmware} \parallel \text{initramfs} \parallel \ldots)$, and signed by a hardware-rooted signing key, the Endorsement Key [2604.26974].

Remote attestation is represented as an attestation report of the form
$$
\mathrm{AttestationReport} = \mathrm{Sign}_{\mathrm{TEE\_SK}}(\mathrm{Measurement} \parallel \mathrm{Nonce}) .
$$
In the RATS-style flow described for C8s, the verifier sends a random nonce $N$, the attester computes
$$
R = \mathrm{Sign}_{sk_{\mathrm{TEE}}}(H_{\mathrm{launch}} \parallel N),
$$
and the verifier checks the signature under the TEE certificate chain, confirms that the launch measurement is in an allow-list, and verifies that the TCB version meets a minimum threshold [2604.26974].

This attestation mechanism is not treated as a peripheral feature. It is the basis for workload identity, certificate issuance, and secret release. A plausible implication is that C8s substitutes measured execution and cryptographic evidence for the kinds of trust assumptions that are normally placed in the control plane, node administrator, or infrastructure operator. The paper’s emphasis on third-party verifiability follows directly from this structure [2604.26974].

## 4. Core components and cryptographic control flows

The architecture’s core components are a confidential VM node image or per-pod CVM runtime, the Certificate Distribution Service (CDS), an NRI image-policy enforcer, a raTLS service-mesh overlay, an attested ingress router with freshness beacons, an attestation-gated secret broker, and, optionally, multi-recipient client-side encryption with an Encrypted Ingress Router [2604.26974].

The CDS is central. It runs as an attested pod with measurement $M_{\mathrm{CDS}}$, is manually attested by the operator at bootstrap, and holds its private signing key only inside TEE memory. Upon successful attestation of a pod $P$, it issues
$$
\mathrm{Cert}_P = \mathrm{Sign}_{SK_{\mathrm{CDS}}}(\mathrm{PubKey}_P, H_{\mathrm{measurement}(P)}, \mathrm{meta}),
$$
which serves as a kube-SPIFFE-style identity for raTLS. Evidence-to-channel binding is then achieved by requiring the pod to generate an ephemeral keypair inside the TEE and produce an attestation report that includes the digest of the public key:
$$
R_P = \mathrm{Sign}_{sk_{\mathrm{TEE}}}(H_{\mathrm{measurement}(P)} \parallel H(pk_P) \parallel N).
$$
CDS refuses to issue the certificate unless the bound public-key digest matches the attested evidence [2604.26974].

Freshness beacons are used to amortize attestation cost. CDS issues a signed timestamp beacon,
$$
\tau = \bigl(\mathrm{Sign}_{SK_{\mathrm{CDS}}}(\text{“c8s/beacon”} \parallel T), T\bigr),
$$
and workloads re-attest with $\tau$ in `REPORT_DATA`. The client checks the beacon signature, the freshness window, and that the attestation embeds $\tau$. In the raTLS mesh handshake, each pod presents its CDS-issued certificate in a standard TLS exchange, and peers verify it under the CDS public key established earlier. The paper states that mTLS session keys based on ECDHE with ephemeral keys protect intra-cluster traffic [2604.26974].

Optional multi-recipient encryption extends these guarantees to payload delivery. The client constructs one symmetric data key $K_{\text{data}}$, wraps it for each pod $i$ as $C_i = \mathrm{Enc}_{pk_i}(K_{\text{data}})$, and forms a payload with wrapped keys and encrypted body:
$$
[\text{header: }\{C_i,\text{ routing\_hint}_i\}_{i=1}^n \parallel \text{body: }\mathrm{Enc}_{K_{\text{data}}}(\text{plaintext})].
$$
The stated overhead is approximately 64 bytes per extra recipient in AGE format [2604.26974].

## 5. Boundary placement in Kubernetes deployments

A defining architectural choice is that the control plane remains entirely outside the trust boundary. The first attested surfaces are the compute nodes or pods. At node level, deployments use EKS, GKE, or AKS Confidential VM node pools. At pod level, which the paper describes as the default, the C8s Pod Runtime spawns a CVM per pod, even on non-CVM nodes, via cloud API peer-pod provisioning [2604.26974].

This boundary placement permits compatibility with managed Kubernetes precisely because attestation-gated enforcement localizes secrecy to nodes or pods rather than the API server. Workloads on non-CVM nodes are denied mesh identity and do not appear in the allow-list. Scheduling, scaling, and network management therefore continue to use the native control plane, but without granting that control plane visibility into plaintext execution within the attested boundary [2604.26974].

The paper also describes a trade-off between node-level and pod-level boundaries. Pod-level isolation gives per-pod isolation but incurs higher VM overhead and per-pod GPU bind. Node-level placement shares GPU across pods but requires tenant-node affinity for hard multi-tenancy. This suggests that C8s is intended as a flexible architecture rather than a single fixed deployment pattern, with boundary placement chosen according to tenancy and accelerator-sharing requirements [2604.26974].

## 6. Representative workloads, comparative position, and nomenclature

The representative workloads named for C8s are AI inference, securing AI model weights, training or fine-tuning on sensitive data, and data analytics in healthcare, legal, and finance. For AI inference, the protected assets include model weights, KV caches, queries, and generations in VRAM and DRAM; for training and fine-tuning, ephemeral activations and datasets are included explicitly. The performance notes given are that CPU TEE overhead is typically a small constant factor for syscall exits, that raTLS mesh throughput matches standard mTLS, that certificate issuance is infrequent with hourly lifetimes, and that a multi-recipient encryption header is approximately 6.4 KB for 100 pods and negligible for payloads [2604.26974].

In comparison with conventional Kubernetes, the paper’s main claim is that ordinary access control plus encryption at rest and in transit leaves a “plaintext gap” in memory, since the hypervisor or host OS can read all memory during compute. C8s is positioned against two existing confidential-Kubernetes approaches. Kata Containers and Confidential Containers are described as using per-pod micro-VMs with independent attestations and key brokers, at high adaptation cost per workload. Edgeless Constellation is described as wrapping the entire cluster, including control and data plane, in CVMs and therefore requiring a self-hosted control plane. By contrast, C8s emphasizes flexible boundary placement, compatibility with managed Kubernetes, a single common CDS for attestation, certificate issuance, and key brokering, and, in most deployments, no changes to application code or container specification [2604.26974].

The label “C8s” should also be distinguished from unrelated materials-science uses of “C8,” which denote octacarbon allotropes rather than confidential-computing systems. The data include tetragonal, cubic, monoclinic, orthorhombic, and hexagonal carbon phases designated C8 or bcc-C$_8$, including “Novel Ultra-hard tetragonal Octacarbon C8 close to Diamond from First Principles” [2206.05918], “Ideal Intersecting Nodal Ring Phonons in a Body-Centered Cubic C$_8$” [1811.09498], “Semimetallic carbon allotrope with topological nodal line in mixed $sp^2$-$sp^3$ bonding networks” [1610.04383], “First principles investigations in the carbon silicon system of novel tetragonal C8 (diamond) and Si8 allotropes and binary Si4C4 phase” [2207.10359], and “Original Ultra-hard Orthorhombic Carbon allotropes C8 with lonsdaleite-type lon topology” [2501.16820]. In current usage, however, the pluralized form “C8s” in arXiv nomenclature refers specifically to the confidential Kubernetes architecture introduced in 2026 [2604.26974].

Source: https://www.emergentmind.com/topics/c8s