---
title: 'dstack: Zero Trust Confidential Systems'
url: https://www.emergentmind.com/topics/dstack
type: topic
---

# dstack: Zero Trust Confidential Systems

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 [2509.11555]. 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 [2606.03323], 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 [2509.11555]) 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 [2606.03323] 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 [2509.11555].

### 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 [2509.11555].

### 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 [2606.03323].

## 4. Algorithms, Protocols, and Measurement Flows

Several critical workflow algorithms appear in the dstack stack:

- **Key Derivation and Secret Provisioning (pseudocode: [2509.11555])**:
  ```python
  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 [2509.11555] and [2606.03323]) 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 [2606.03323].
- 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 [2304.13541].

## 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 [2304.13541].

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.

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