pith. sign in

arxiv: 2604.26974 · v1 · submitted 2026-04-27 · 💻 cs.CR · cs.ET

C8s: A Confidential Kubernetes Architecture

Amean Asad , Patrick McClurg , Jo\~ao Andrade This is my paper

Pith reviewed 2026-05-08 02:29 UTC · model grok-4.3

classification 💻 cs.CR cs.ET
keywords confidential computingKubernetestrusted execution environmentscloud securityattestationAI model protection
0
0 comments X

The pith

C8s wraps Kubernetes in attested confidential VMs to deliver cryptographically provable confidentiality and integrity even when the control plane runs outside the trust boundary.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents C8s as a confidential computing architecture for Kubernetes clusters that roots its security claims in hardware trusted execution environments. It targets managed services such as EKS, GKE, and AKS where the control plane itself cannot be attested. The design lets data owners run sensitive workloads and proprietary artifacts on third-party infrastructure while giving compute providers a way to host execution without exposing the workloads. End users gain the ability to submit requests that stay opaque to everyone except the attested processing environment. These properties are intended to be verifiable by any independent third party through cryptographic attestation.

Core claim

C8s establishes an attestation-rooted trust boundary around confidential virtual machines using AMD SEV-SNP, Intel TDX, and NVIDIA Confidential Computing support. This boundary isolates Kubernetes workloads from infrastructure operators and the unattested control plane, allowing cryptographically provable guarantees of confidentiality, integrity, and verifiability to be offered to data owners, compute providers, and end users.

What carries the argument

The attestation-rooted trust boundary around confidential VMs, which isolates workloads and generates verifiable proofs independent of the Kubernetes control plane.

If this is right

  • Data owners can deploy AI inference, model training, and fine-tuning workloads on third-party clouds without risking exfiltration of sensitive data or artifacts.
  • Compute providers can offer execution services while keeping customer workloads hidden from cloud operators.
  • End users can send requests that remain private to all parties except the attested TEE processing them.
  • The architecture remains compatible with existing managed Kubernetes offerings where the control plane cannot be placed inside the trust boundary.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same boundary construction could support confidential orchestration of multi-tenant AI serving platforms where model weights from different owners must stay isolated.
  • Operators of regulated industries might use C8s to meet data residency or processing requirements without maintaining fully private infrastructure.
  • Future extensions could add policy enforcement layers inside the attested boundary to control data flows between workloads.

Load-bearing premise

The selected hardware TEEs maintain their isolation and attestation guarantees even though the Kubernetes control plane operates outside the attested boundary.

What would settle it

An experiment in which an infrastructure operator successfully extracts model weights or input data from a running C8s workload despite valid attestation reports from the TEE would falsify the claimed guarantees.

Figures

Figures reproduced from arXiv: 2604.26974 by Amean Asad, Jo\~ao Andrade, Patrick McClurg.

Figure 1
Figure 1. Figure 1: The three-sided trust problem. Artifact owners, compute providers, and end users share infrastructure none of them controls; every confidentiality boundary between them is enforced by contract rather than by cryptography. 1.2 Problem Statement The core challenge is to construct a deployment architecture for sensitive workloads on Kubernetes in which: 1. Workload inputs, outputs, and intermediate computatio… view at source ↗
Figure 2
Figure 2. Figure 2: The CVM boundary and attestation report. A digest covering firmware, initrd, kernel, user space, and the deployed workload is signed by hardware-rooted keys and produced as the attestation report; nothing outside the boundary can observe or modify the measured layers. AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) [1] and Intel Trust Domain Extensions (TDX) [2] implement these prop… view at source ↗
Figure 3
Figure 3. Figure 3: Standard Kubernetes topology. The control plane schedules pods onto nodes; an external load balancer distributes client traffic. No confidentiality enforcement is present. 2.3 Related Work Prior work on confidential computing in Kubernetes, including Kata Containers [6] and the Confidential Containers (CoCo) project [7], has focused on per-pod isolation by running each pod in its own micro-VM with an indep… view at source ↗
Figure 4
Figure 4. Figure 4: Standard Kubernetes vs. C8s. The control plane remains outside the trust boundary in both cases; under C8s, every node and the ingress are CVMs holding CDS-issued identities, and intra-cluster traffic runs over the raTLS mesh. 12 view at source ↗
Figure 5
Figure 5. Figure 5: Pod-level CVM anatomy. The host is an ordinary VM acting as a control surface; every pod boots inside its own confidential VM whose measured boot chain covers the in-pod services that gate image pulls and present mesh identity. 5.1.1 Image-gap Mechanisms A per-pod launch digest covers the software that measures at boot, but not the container image, which is pulled from a registry after the pod is already r… view at source ↗
Figure 6
Figure 6. Figure 6: Three image-gap mechanisms. All three anchor on something inside the pod’s launch digest; they differ in whether the measured anchor is an allow-list, a signing key, or a decryption key. 5.2 Node-level CVM When the trust boundary is drawn around the worker node rather than the pod, each Kubernetes node runs as a CVM. At boot, the hardware’s secure processor computes a launch measurement covering the firmwa… view at source ↗
Figure 7
Figure 7. Figure 7: Node-level CVM anatomy. The entire worker node boots as a confidential VM; customer pods, the Kubernetes runtime, and the C8s services (attestation, NRI policy, mesh proxy) all share the node’s hardware-encrypted memory. Applying the design formula from §4.2: 1. The node runs as a CVM; the TEE encrypts VM memory with keys the hypervisor never possesses. 2. The secure processor computes a launch measurement… view at source ↗
Figure 8
Figure 8. Figure 8: GPU attachment comparison. Node-level deployments can time-slice or partition a single attached GPU across pods; pod-level deployments dedicate a whole GPU (or whole partition) to each pod’s CVM because CC mode binds the protected context to one guest. 5.5 Choosing Where to Draw the Boundary The choice between a node-level and a pod-level boundary is a deployment-time configuration, not two separate produc… view at source ↗
Figure 9
Figure 9. Figure 9: Node-level vs. pod-level boundary. Same CDS, same mesh, same key-release machinery on both sides; what moves is where the CVM wall sits and which components end up inside it. The trade-offs in summary: 19 view at source ↗
Figure 10
Figure 10. Figure 10: CDS responsibilities. The CDS is itself a CVM manually attested by the operator at bootstrap; from there, every outgoing channel is anchored in an attestation decision. 5.6.1 Deployment Model The CDS is deployed as an active/active pair so it does not become a single point of failure. Each replica runs as an attested pod with the same measurement and serves traffic independently. A 21 view at source ↗
Figure 11
Figure 11. Figure 11: CDS bootstrapping. The operator attests the CDS measurement once; this covers every replica at that measurement, present and future. Consequences of unavailability. If the CDS becomes unavailable, existing certificates keep working until they expire. New attested pods cannot obtain certificates, so new pods cannot join the mesh. Running workloads are unaffected for the lifetime of their existing certifica… view at source ↗
Figure 12
Figure 12. Figure 12: Attestation-gated key delivery. The CDS releases a secret only when all three release conditions match; the attested pod fetches ciphertext from untrusted storage and decrypts it exclusively inside CVM-encrypted memory. Multi-key isolation. Each secret has its own release policy, and the CDS ties release to specific workload measurements rather than to which node or pod hosts the workload. Two providers’ … view at source ↗
Figure 13
Figure 13. Figure 13: Vault integration. The attestation-gated proxy sits inside the trust boundary; the external vault never sees a workload directly, only the proxy’s identity after attestation and policy pass. 5.7 NRI Image Policy Enforcer In standard Kubernetes, the control plane dictates what runs on each node. The scheduler selects a node, the API server instructs the kubelet, and the kubelet directs the container runtim… view at source ↗
Figure 14
Figure 14. Figure 14: Container startup under NRI enforcement. The policy manifest is local and CDS-signed, so the rejection decision is independent of any live control-plane interaction. The NRI enforcer as described here operates at the node, which is appropriate when the node is the CVM and the host can see every container before it starts. When the trust boundary is drawn at the pod, the host cannot observe the post-boot c… view at source ↗
Figure 15
Figure 15. Figure 15: Pod-to-pod mesh flow. Mesh1 and Mesh2 are the node-level mesh proxies on Pod A’s and Pod B’s nodes respectively. The workload observes plaintext on both ends; raTLS with per-pod certificates is terminated at the node-level proxy on each side. 5.8.1 Identity Granularity Every pod receives its own CDS-issued certificate (the pod is always the unit of identity), but there are two reasonable choices for where… view at source ↗
Figure 16
Figure 16. Figure 16: Two identity-holding arrangements. Both preserve pod-level identity on the wire; they differ in whether the certificate lives in a shared node-level proxy or in a sidecar colocated with each pod. 5.8.2 Freshness and Binding Two concerns recur in attested TLS designs. Both have seen formal analysis and both admit a straightforward architectural answer. C8s addresses them by construction rather than as afte… view at source ↗
Figure 17
Figure 17. Figure 17: Client connection flow. The manifest fetch is amortized through caching and periodic refresh, and each request only exercises the lower half of the diagram. The multi-recipient encryption step is optional. By default the client submits the request over ordinary HTTPS and the ingress router does the raTLS forwarding. 5.9.4 Response Path Attested workloads include attestation metadata in response headers, e… view at source ↗
Figure 18
Figure 18. Figure 18: Default ingress path. The ingress router is itself an attested CVM; it terminates external TLS, then relays requests to the destination pod over raTLS. No other cluster component ever sees request payloads in plaintext. 5.10.2 Optional: Encrypted Ingress Router Some deployments want a stronger property, where the ingress never sees plaintext, not even briefly inside its own CVM. This is useful when the cl… view at source ↗
Figure 19
Figure 19. Figure 19: Encrypted Ingress Router topology. Cloud ingress distributes TCP to nodes without understanding the encryption format. A per-node router (attested DaemonSet) parses recipient hints and forwards ciphertext to a local pod or a peer router on another node. No decryption happens in the router; at most one intra-cluster hop across the mesh. Why per-node rather than centralized. A single centralized payload-awa… view at source ↗
Figure 20
Figure 20. Figure 20: End-to-end request lifecycle in the default configuration. Dashed bands mark the subsection boundaries used in the rest of this section. The optional client-side multi-recipient encryption path (§5.9.3) replaces the HTTPS POST step with a ciphertext payload routed by hostname hints (see §5.10.2). 40 view at source ↗
Figure 21
Figure 21. Figure 21: OHTTP relay topology. Each hop sees either the client identity or the payload, never both; the relay cannot decrypt the OHTTP envelope, and the gateway cannot see the originating client. 9 Discussion 9.1 Trust Assumptions The architecture concentrates trust in hardware manufacturers (AMD, Intel) and the code running inside measured TEEs. The CDS is explicitly trusted as the root of the certificate chain. 43 view at source ↗
read the original abstract

This paper presents C8s, a confidential computing architecture for Kubernetes that provides cryptographically rooted confidentiality, integrity, and verifiability guarantees for Kubernetes clusters from infrastructure operators. These guarantees are cryptographically provable to any independent third party verifier. The architecture is built on hardware Trusted Execution Environments (TEEs), specifically AMD SEV-SNP, Intel TDX, and NVIDIA Confidential Computing support, to establish an attestation-rooted trust boundary around confidential VMs. This design is compatible with managed Kubernetes services such as Amazon EKS, Google GKE, and Microsoft AKS, where the control plane cannot be attested. Under this boundary, three groups gain guarantees that are absent from conventional deployments. 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. End users can submit requests that remain opaque to all parties except the attested TEE processing them. Representative workloads include AI inference, securing AI model weights, and training or fine-tuning on sensitive data.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper presents C8s, a confidential computing architecture for Kubernetes that uses hardware TEEs (AMD SEV-SNP, Intel TDX, NVIDIA Confidential Computing) to establish an attestation-rooted trust boundary around confidential VMs. It claims to deliver cryptographically provable confidentiality, integrity, and verifiability guarantees to third-party verifiers for workloads on managed Kubernetes services (EKS, GKE, AKS) where the control plane cannot be attested. The architecture targets protection for data owners, compute providers, and end users in sensitive scenarios such as AI inference, model weight protection, and training on proprietary data.

Significance. If the architecture is sound and the TEE assumptions hold, C8s would address a practical gap in confidential computing by enabling verifiable secure execution on untrusted managed Kubernetes platforms without requiring attestation of the control plane. This has clear relevance for privacy-sensitive applications in AI and cloud computing, where current solutions either demand full-stack attestation or accept operator trust.

major comments (2)
  1. The central claim that cryptographically rooted guarantees hold despite an unattested control plane (handling pod specs, scheduling, secrets, and kubelet communication) is load-bearing but unsupported by any described mechanism for binding attested VM state to a specific workload manifest or for preventing control-plane-induced side effects such as manifest tampering or network configuration that could enable exfiltration.
  2. No threat model, security analysis, or formal argument is provided to show why standard TEE attestation (SEV-SNP, TDX, NVIDIA CC) suffices to protect workloads when the Kubernetes control plane runs outside the attested boundary and cannot itself be verified.
minor comments (1)
  1. The abstract and high-level description would benefit from explicit definitions of the exact properties being attested and the verifier's view of the system.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their constructive feedback on our manuscript describing the C8s architecture. We agree that additional details on the binding mechanisms and a formal security analysis would strengthen the paper, and we outline our plans to address these points below.

read point-by-point responses

  1. Referee: The central claim that cryptographically rooted guarantees hold despite an unattested control plane (handling pod specs, scheduling, secrets, and kubelet communication) is load-bearing but unsupported by any described mechanism for binding attested VM state to a specific workload manifest or for preventing control-plane-induced side effects such as manifest tampering or network configuration that could enable exfiltration.

    Authors: The manuscript describes the use of attested confidential VMs as the trust boundary, with workloads executing inside them, but we recognize that the binding between the attested VM state and the specific Kubernetes workload manifest is not detailed sufficiently. In the revision, we will include a new subsection on 'Attestation and Workload Binding' that explains how the TEE verifies the integrity of the pod specification and container images via measurements included in the attestation report. We will also discuss mitigations for control-plane side effects, such as enforcing all network traffic through attested proxies within the VM and handling secrets via attested key management services. This addresses the potential for manifest tampering by ensuring that any deviation would invalidate the attestation. revision: yes

  2. Referee: No threat model, security analysis, or formal argument is provided to show why standard TEE attestation (SEV-SNP, TDX, NVIDIA CC) suffices to protect workloads when the Kubernetes control plane runs outside the attested boundary and cannot itself be verified.

    Authors: We acknowledge the absence of an explicit threat model in the current version. The architecture relies on the standard properties of the TEEs (memory isolation, remote attestation) to protect the workload execution, assuming the control plane can only influence scheduling and configuration but not the runtime inside the TEE. In the revised manuscript, we will add a dedicated 'Threat Model and Security Analysis' section. This will formally define the adversary as the infrastructure operator with control over the Kubernetes control plane, list the assumptions on TEE security (e.g., no side-channel attacks beyond current mitigations), and provide arguments why attestation of the VM suffices to ensure confidentiality and integrity of the workload despite the unattested control plane. We will include informal proofs for key properties and discuss limitations. revision: yes

Circularity Check

0 steps flagged

No circularity: architectural construction without derivation or fitting

full rationale

The paper describes a system architecture for confidential Kubernetes clusters built on TEE hardware (AMD SEV-SNP, Intel TDX, NVIDIA CC) and compatible with managed services. No equations, parameter fitting, predictions, or self-referential definitions appear in the provided abstract or description. Claims rest on assumed TEE isolation properties and design choices rather than any reduction to inputs by construction, self-citation chains, or renamed empirical patterns. The architecture is presented as a self-contained construction whose guarantees follow from the stated TEE boundaries and compatibility assertions.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The architecture rests on the security properties of commercial TEE hardware and on the ability to establish an attestation root even when the control plane is untrusted. No free parameters or new invented entities are introduced in the abstract.

axioms (1)
  • domain assumption Hardware TEEs such as AMD SEV-SNP, Intel TDX and NVIDIA Confidential Computing provide strong memory isolation and remote attestation that cannot be bypassed by the cloud hypervisor or operator.
    The entire trust boundary is built on these hardware guarantees; the abstract invokes them as the root of confidentiality and verifiability.

pith-pipeline@v0.9.0 · 5480 in / 1316 out tokens · 64510 ms · 2026-05-08T02:29:06.776677+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

24 extracted references · 24 canonical work pages

  1. [1]

    AMD White Paper, 2020

    AMD.AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More. AMD White Paper, 2020

    work page 2020

  2. [2]

    Intel, 2023

    Intel.Intel Trust Domain Extensions (Intel TDX) Module Base Architecture Specification. Intel, 2023

    work page 2023

  3. [3]

    NVIDIA Technical Brief, 2023

    NVIDIA.NVIDIA Confidential Computing. NVIDIA Technical Brief, 2023

    work page 2023

  4. [4]

    https://github.com/lunal-dev/home/blob/ main/blog/tee-performance-cpus.md, 2025

    confidential.ai.TEE Performance on CPUs. https://github.com/lunal-dev/home/blob/ main/blog/tee-performance-cpus.md, 2025

    work page 2025

  5. [5]

    W. Kwon, Z. Li, S. Zhuang, et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. InProceedings of the 29th Symposium on Operating Systems Principles (SOSP), 2023

    work page 2023

  6. [6]

    https://katacontainers.io, 2024

    Kata Containers.Kata Containers Architecture. https://katacontainers.io, 2024

    work page 2024

  7. [7]

    https://github.com/ confidential-containers, 2024

    Confidential Containers.CoCo Project Documentation. https://github.com/ confidential-containers, 2024

    work page 2024

  8. [8]

    V. Shoup. A Proposal for an ISO Standard for Public Key Encryption.Cryptology ePrint Archive, Report 2001/112, 2001

    work page 2001

  9. [9]

    Fiat and M

    A. Fiat and M. Naor. Broadcast Encryption. InAdvances in Cryptology (CRYPTO), 1993

    work page 1993

  10. [10]

    Valsorda.The age File Encryption Format

    F. Valsorda.The age File Encryption Format. https://age-encryption.org/v1, 2019

    work page 2019

  11. [11]

    Morbitzer, M

    M. Morbitzer, M. Huber, J. Horsch, and S. Wessel. SEVered: Subverting AMD’s Virtual Machine Encryption. InProceedings of the 11th European Workshop on Systems Security (EuroSec), ACM, 2018

    work page 2018

  12. [12]

    https://www.vaultproject.io, 2024

    HashiCorp.Vault by HashiCorp. https://www.vaultproject.io, 2024

    work page 2024

  13. [13]

    https://github.com/containerd/nri, 2023

    Kubernetes.Node Resource Interface (NRI). https://github.com/containerd/nri, 2023

    work page 2023

  14. [14]

    Thomson and C

    M. Thomson and C. A. Wood. Oblivious HTTP.RFC 9458, IETF, 2024

    work page 2024

  15. [15]

    Birkholz, D

    H. Birkholz, D. Thaler, M. Richardson, N. Smith, and W. Pan. Remote ATtestation procedureS (RATS) Architecture.RFC 9334, IETF, 2023. https://datatracker.ietf.org/doc/ html/rfc9334

    work page 2023

  16. [16]

    Barnes, K

    R. Barnes, K. Bhargavan, B. Lipp, and C. Wood. Hybrid Public Key Encryption.RFC 9180, IETF, 2022. https://datatracker.ietf.org/doc/html/rfc9180

    work page 2022

  17. [17]

    Williams

    N. Williams. On the Use of Channel Bindings to Secure Channels.RFC 5056, IETF, 2007. https://datatracker.ietf.org/doc/html/rfc5056

    work page 2007

  18. [18]

    https://istio.io, 2024

    Istio Authors.Istio Service Mesh. https://istio.io, 2024

    work page 2024

  19. [19]

    https://spiffe.io, 2024

    SPIFFE.Secure Production Identity Framework for Everyone. https://spiffe.io, 2024

    work page 2024

  20. [20]

    https: //github.com/sigstore/cosign, 2024

    Sigstore.Cosign: Container Signing, Verification and Storage in an OCI Registry. https: //github.com/sigstore/cosign, 2024. 46

    work page 2024

  21. [21]

    Chuang, A

    J. Chuang, A. Seto, N. Berrios, S. van Schaik, C. Garman, and D. Genkin. TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition. In47th IEEE Symposium on Security and Privacy (S&P ’26), IEEE, 2026

    work page 2026

  22. [22]

    De Meulemeester, D

    J. De Meulemeester, D. Oswald, I. Verbauwhede, and J. Van Bulck. Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing. In 47th IEEE Symposium on Security and Privacy (S&P ’26), IEEE, 2026

    work page 2026

  23. [23]

    De Meulemeester, L

    J. De Meulemeester, L. Wilke, D. Oswald, T. Eisenbarth, I. Verbauwhede, and J. Van Bulck. BadRAM: Practical Memory Aliasing Attacks on Trusted Execution Environments. In46th IEEE Symposium on Security and Privacy (S&P ’25), IEEE, 2025

    work page 2025

  24. [24]

    Constellation: Confidential Kubernetes

    Edgeless Systems. Constellation: Confidential Kubernetes. https://github.com/edgelesssys/ constellation, 2024. 47

    work page 2024