dstack: Zero Trust Confidential Systems

• dstack is a family of secure systems for confidential container orchestration, integrating zero-trust frameworks and fine-grained cryptographic controls.
• It combines components like dstack-OS, dstack-KMS, and dstack-Gateway to deliver decentralized governance, hardware-backed attestation, and multi-layer isolation.
• Innovations include portable confidential containers, pod-level remote attestation in Kubernetes, and efficient GPU scheduling for high-throughput deep learning.

Dstack encompasses a family of systems for secure, efficient, and high-trust orchestration of computation: most notably, (1) dstack—a zero trust framework for confidential container workloads; (2) dstack-capsule—a Kubernetes extension for dense, Pod-level attestation atop confidential VMs; and (3) D-STACK—a GPU multiplexing scheduler for high-throughput DNN inference. In the context of confidential computing and advanced cloud orchestration, dstack frameworks address crucial limitations of commodity TEEs and secure scheduling by integrating strict hardware-backed attestation, decentralized control, multi-layer isolation, and portable container semantics. While these systems target orthogonal layers of infrastructure, all share a focus on maximizing trust transparency, minimizing resource overhead, and enforcing fine-grained cryptographic policy at scale.

1. Security Requirements and Threat Model

Dstack is engineered to remove any single point of trust within confidential computation platforms, particularly for Web3 and multi-tenant cloud scenarios (Zhou et al., 15 Sep 2025). The baseline threat model assumes:

• Adversaries may include malicious application deployers, cloud or platform operators, and network attackers (capable of DNS hijack, MITM).
• TEEs are trusted only for basic isolation and attestation; undetected hardware vulnerabilities are out of scope.
• For dstack-capsule (Yang et al., 2 Jun 2026), the adversary controls the hypervisor, host OS, and Kubernetes control plane, in addition to possible malicious workload developers.

The security invariants enforced are: confidentiality, code and data integrity, censorship resistance, decentralized governance, and verifiable chain-of-trust from deployment to service endpoint. All critical cryptographic operations chain from governance-controlled KMS roots, and dynamic workload identity is cryptographically bound to attestation evidence.

2. Core Architectural Components

Dstack frameworks (as defined in (Zhou et al., 15 Sep 2025)) are realized through three orthogonal but cooperating subsystems:

Component	Functionality	Security Mechanisms
dstack-OS	Minimal OS/bootloader/container stack for TEEs; attestation of every stage, Docker-compatible workloads	PCR/RTMR chain-of-trust, encrypted volumes
dstack-KMS	Blockchain-governed Key Management Service; P2P nodes in TEEs; on-chain application approval registry	Attested KMS, HKDF key derivations, Shamir MPC
dstack-Gateway	Reverse proxy in TEE; verifiable domain/TLS endpoint; wildcard DNS	ZT-TLS protocol, on-chain CA keys, CT log auditing

Dstack-capsule (Yang et al., 2 Jun 2026) adds a Pod-aware attestation agent for Kubernetes, specifically supporting Intel TDX:

• The platform attests foundational components (OVMF firmware, UKI, root hash) using RTMR registers (static, append-only).
• A "privilege fuse" transition enforces immutable node state: once fused, only non-privileged Pods are accepted.
• Each Pod is attested by embedding its (pod_uid, pod_spec_hash, workload_id) triple in the TDX Quote report_data, yielding per-Pod hardware proofs.

3. Innovations in Confidential Containers and Attestation

3.1 Portable Confidential Containers

Traditional TEE sealing is device-bound: only the TEE that sealed state can unseal it. Dstack generalizes this to enable migration and redundancy:

• Confidential container state is encrypted under a per-application key derived from a global RootKey RK managed via dstack-KMS and application config hash.
• Key derivation is standardized via HKDF:

$$\text{DEK} = HKDF(RK, \text{`disk`} \parallel \text{AppID} \parallel \text{InstanceID})$$

• Migration property: authorized TEEs obtain the same DEK and can decrypt/mount state seamlessly.
• Theoretical guarantees (under the security of HKDF and secrecy of RK): indistinguishability of encrypted state, and resilience to TEE failure or migration (Zhou et al., 15 Sep 2025).

3.2 Decentralized Code and Domain Governance

• Application identity is cryptographically ratified via on-chain contracts (KmsAuth, AppAuth_app), with application code hashes and operator keys recorded on-chain.
• Key distribution is managed by a TEE-only KMS cluster, with root keys shared via simple replication or MPC Shamir thresholding.
• Domain management (ZT-TLS): TLS certificates are issued from a CA whose keys are derived from RK and AppID. Browsers can verify certificate origin back to on-chain root, CAA DNS records, and TEE attestation quotes (Zhou et al., 15 Sep 2025).

3.3 Pod-Level Remote Attestation for Kubernetes

• dstack-capsule introduces the concept of hardware-backed attestation at the Pod granularity while sharing the underlying CVM (Confidential VM).
• Two-level attestation: platform integrity frozen at setup (via immutable RTMR[3]), dynamic Pod identities enforced per request via signed TDX Quotes.
• Multi-layer sandbox: Storage (ZFS + per-Pod disk keys), runtime (Sysbox user-namespace UID remapping), admission control (deny privileged contexts post-fuse), API gating (Kubelet and gRPC), and WireGuard-enforced per-Pod VPCs (Yang et al., 2 Jun 2026).

4. Algorithms, Protocols, and Measurement Flows

Several critical workflow algorithms appear in the dstack stack:

• Key Derivation and Secret Provisioning (pseudocode: (Zhou et al., 15 Sep 2025)):

def handle_secret_request(quote, codeHash, appID, domain=None): assert verify_attestation_quote(quote, codeHash) if not KmsAuth.AuthorizedApp(appID, codeHash): reject("unauthorized code version") RK = derive_root_key(appID) DEK = HKDF(RK, b"disk" + appID + instanceID) ENVK = HKDF(RK, b"env" + appID) TLSsk = HKDF(RK, b"tls" + appID) return { "DEK": DEK, "ENVK": ENVK, "TLSsk": TLSsk }

• dstack-OS Boot Measurement Chain:

1. Hypervisor → PCR0
2. OVMF → PCR1
3. Kernel → PCR2
4. initrd → PCR3
5. RootFs → PCR4
6. Container image digest → PCR5

• ZT-TLS Handshake: Certificate and attestation evidence are chained to the AppAuth on-chain record and verified by the browser.

In dstack-capsule, the Pod-level attestation protocol involves:

• Identifying true caller identity (SO_PEERCRED + cgroup)
• Embedding identity triplet in TDX Quote report_data
• External verification by recomputation and signature check:

$$\hat r = H_{SHA256}(\text{pod\_uid} \parallel \text{pod\_spec\_hash} \parallel \text{workload\_id})$$

and require $\hat r$ matches the quote.

5. Performance Evaluation

Reported benchmarks (from (Zhou et al., 15 Sep 2025) and (Yang et al., 2 Jun 2026)) indicate:

Metric	dstack/dstack-capsule	Baseline/Alternative
Container startup overhead	+3–5% over native TDX VM	Native TDX VM
Secret fetch latency (dstack-KMS)	150 ms (simple), +50 ms MPC	100 ms (raw HW-sealing)
TLS throughput (dstack-Gateway)	within 10% of native nginx	nginx
Integration effort	<1 hr (5-container service)	—
Pod startup latency	6.25 s	8.85 s (CoCo kata-qemu-tdx)
Mem per idle Pod	~2 MB	~2075 MB (CoCo)
Platform baseline mem	~793 MB	N/A
Scale (86 Pods/64 GB node)	Passes Kubelet max-pods=110	CoCo OOM at 30 Pods

A plausible implication is that dstack frameworks scale efficiently in high-density, multi-tenant environments while imposing only minimal performance overhead and providing cryptographically robust attestation per workload.

6. Limitations and Future Directions

Identified limitations include:

• Side-channel and microcode attacks remain out-of-scope; future hardware or formal protocol analyses (e.g., Tamarin, ProVerif) are needed (Yang et al., 2 Jun 2026).
• In dstack-capsule, Pod identity is not directly fused into RTMR, shifting some trust to dstack-agent, albeit hardware-attested.
• Extension to additional TEE types (e.g., AMD SEV-SNP, NVIDIA GPU TEEs) and support for bare-metal benchmarking are planned.
• For D-STACK, limitations with CUDA MPS (no kernel-level preemption, static GPU partitioning) and the need for manual model profiling remain open optimization areas (Dhakal et al., 2023).

7. Sibling Technologies and Related Work

Dstack’s approach contrasts sharply with traditional Confidential Container architectures (e.g., CoCo’s “one Pod per VM” model) by offering both denser packing and per-workload attestation. It addresses fundamental gaps in migration, multi-tenancy, and trust transparency absent from baseline TEE stacks. The D-STACK scheduler provides a complementary, non-overlapping contribution to high-throughput, SLO-aware GPU workload consolidation via spatio-temporal scheduling and analytic modeling (Dhakal et al., 2023).

Overall, the dstack suite exemplifies the ongoing integration of advanced cryptographic governance, multi-layered attestation, and efficient resource multiplexing in service of robust, Zero-Trust confidential computing.