Portable Confidential Containers Explained

• Portable confidential containers are execution artifacts that deploy containerized workloads with attestation, encryption, and minimal trust across heterogeneous TEEs.
• They integrate various isolation techniques—from TEE-in-container to VM-based approaches—balancing security, performance, and portability.
• Implementation strategies emphasize attestation-driven workflows, reduced trusted computing bases, and seamless migration across platforms, ensuring robust integrity and confidentiality.

A portable confidential container (PCC) is an execution artifact and operational abstraction that allows unmodified or lightly adapted containerized workloads to be deployed, migrated, and attested as confidential workloads across heterogeneous trusted execution environments (TEEs). By integrating attestation, memory and disk encryption, and minimal trust assumptions into standard container workflows, PCCs address the need for data-in-use confidentiality, integrity, and verifiability, especially under strong adversary models in cloud and multi-tenant contexts. The ecosystem encompasses a spectrum of approaches: software-only library-OSes, VM-based containerization, WebAssembly sandboxes, and composite REE+TEE lifecycles, all aiming to minimize the trusted computing base (TCB), mediate untrusted interfaces, and enforce strict cryptographic roots-of-trust.

1. Architectural Patterns and Trust Models

Portable confidential containers can be realized through multiple system designs, each reflecting distinct trade-offs in TCB, isolation granularity, and workload compatibility.

• TEE-in-Container (e.g., Arca): Each OCI-style container is instantiated with its own hardware-backed enclave or confidential VM. Only the security-critical application logic and a minimal agent reside in the TEE; all orchestration, runtime management, and control-plane logic remain in the untrusted domain. This design ensures per-container trust domains, enables straightforward attestation per workload, and caps the TCB at approximately 5–10 KLOC (agent enclave) plus user code (Lu et al., 3 Jan 2026).
• VM-based Confidential Containers (e.g., Trusted Container Extensions, Parma, CoCo): Container(s) or container groups are encapsulated within a confidential VM (e.g., AMD SEV/SEV-SNP, Intel TDX). Root-of-trust is established at VM launch via measured boot and attestation reports, endorsing not only code but also layered filesystem and policy state. Guest agents enforce policies over all in-VM container actions, enabling “lift-and-shift” with no code changes—at the expense of a higher TCB (guest OS, agent, and kernel components) (Brasser et al., 2022, Johnson et al., 2023, Ye et al., 2024).
• Composite OCI+TEE Pipelines (e.g., EBCC): Secure computing stages are integrated behind an OCI-compatible adapter, allowing the REE-side (e.g., crun) to manage lifecycles and dispatch confidential workloads to arbitrary TEE backends via narrow, versioned interfaces. This architectural separation enables uniformity across enclave-style, VM-style, and embedded (e.g., OP-TEE) TEEs (Lu et al., 13 May 2026).
• WebAssembly-based Containers and SFI (e.g., Enarx, AccTee, Occlum AE): WASM runtimes or compiler-instrumented SFI/DBT constructs enforce in-enclave process isolation, code/data access policies, and structured control flows. The strong typing and execution invariants of WASM are applied inside TEEs to further limit the blast radius if untrusted modules or user code are loaded (Liu et al., 2021, Liu et al., 28 Aug 2025).
• Pod-Level Multi-Tenancy (e.g., dstack-capsule): Per-Pod attestation and isolation are realized inside shared confidential VMs. Hardware-level identity binding is achieved via decoupled platform (static) and pod-level (dynamic) measurements, enabling granular remote attestation and minimizing per-pod resource costs (Yang et al., 2 Jun 2026).

Threat models universally assume that the host OS, hypervisor, and all infrastructure APIs outside the TEE are adversary-controlled, focusing all trust exclusively on hardware-provided primitives (attestation, memory encryption, CPU-based roots-of-trust). Residual TCB is carefully bounded to the code and configuration attested at launch.

2. Security Guarantees and Attestation Protocols

PCC designs provide layered confidentiality, integrity, and verifiability properties anchored in hardware-enforced isolation, cryptographic measurement, and cryptographically-bound secret provisioning.

• Isolation and Containment: Each confidential container (enclave or VM) is instantiated and attested independently, ensuring that compromise of one trust domain cannot propagate laterally. In per-container-enclave models, e.g., Arca and dstack-capsule, breach isolation is at workload or Pod granularity (Lu et al., 3 Jan 2026, Yang et al., 2 Jun 2026).
• Remote Attestation and Measurement: Every container or VM is measured (e.g., $MRENCLAVE$, TDREPORT, SEV_ATTEST_REPORT), with persistent or policy-based secrets provisioned only after the attestation quote and post-boot PCRs match expected values. For advanced deployments, attestation includes the full code, configuration, and signed policy overlays (e.g., execution policy $π$ in Parma, measured as part of the VM launch digest) (Johnson et al., 2023).
• Secret Derivation and Forward Secrecy: Most designs (e.g., dstack) eschew persistent secret storage, deriving workload keys from hardware-fused roots and measured inputs (e.g., $K_s = f_{KDF}(Z, MRENCLAVE_k)$ or via threshold schemes using HKDF and Shamir’s secret sharing) (Zhou et al., 15 Sep 2025). This allows seamless workload migration across clouds and TEE types without re-encryption or secret exposure.
• Defenses Against Rollback and Replay: Monotonic counters or Merkle-tree-backed integrity provide (to varying degrees) protection against state replay; rollback resistance is strongest when hardware or protocol supports atomic, non-reusable state numbers on every seal/unseal or disk write (Zhou et al., 15 Sep 2025, Johnson et al., 2023).
• Side-Channel and Iago Attack Mitigations: Most practical systems declare side-channels out-of-scope, with partial defenses (e.g., some interrupt and syscall-based mitigations in Graphene-SGX, minimal timing channel awareness elsewhere) (Liu et al., 2021, Liu et al., 28 Aug 2025). Iago attack risk is addressed by minimizing, mediating, and parameter-checking all untrusted OS interface invocations (syscalls, Ocalls, virtio) (Liu et al., 28 Aug 2025).

Sample attestation trace in dstack-capsule (Pod-level):

1. Pod sends $AttestReq(ps, pu, wi)$ to dstack-agent via UDS.
2. Agent computes $rd = H(ps \| pu \| wi)$, signs pod proof.
3. Agent requests TDX quote from hardware with $rd$ embedded.
4. Pod receives $AttestResp(Quote, event\_log, rd)$, which is submitted to verifier that checks signature, static measurements, and pod digests (Yang et al., 2 Jun 2026).

3. Implementation Strategies, Portability, and Lifecycle Integration

PCCs are engineered to maximize portability across TEE substrates, orchestration platforms, and container workflows. Approaches include:

• Library OS Abstraction (LibOS, e.g., Occlum, Gramine): Abstract platform-specific TEE glue behind a thin portability layer, so that SGX, TDX, and SEV can reuse most of the guest stack (Liu et al., 28 Aug 2025).
• OCI and Docker Compatibility: Implementations such as EBCC and TCX maintain full compatibility with OCI/Docker lifecycle primitives (create, start, state, kill, delete) by interposing or adapting the runtime with confidential-computing–aware backends or shims (Lu et al., 13 May 2026, Brasser et al., 2022).
• Filesystem and Storage Integrity: Integrity and confidentiality are enforced via dm-verity, dm-crypt for block devices, gocryptfs sidecars, or kernel-native encrypted filesystems, all bounded by attestation (Ye et al., 2024, Johnson et al., 2023).
• Networking: Data-in-motion confidentiality is implemented via mTLS proxies (e.g., Envoy sidecars, WireGuard VPC), with keys injected post-attestation. Attested network policies can be cryptographically tied to Pod or workload identity (Ye et al., 2024, Yang et al., 2 Jun 2026).
• Deployment Patterns: Steps include container image signing, runtime class or admission controller installation, pod or workload launch with attestation-blessed keys and secrets, with no modifications needed to OCI workflows or standard registries (Ye et al., 2024, Brasser et al., 2022).

Portability is demonstrated by zero image modifications during migration between Intel TDX and AMD SEV-SNP hosts, plug-and-play runtime adaptation (dstack-OS abstracts TEE details), and backend-agnostic design in EBCC that supports SGX, TDX, ARM CCA, and OP-TEE backends via uniform interfaces (Zhou et al., 15 Sep 2025, Lu et al., 13 May 2026).

4. Performance Characteristics and Overheads

Overheads stem from mediation of the container lifecycle, enclave/VM transitions, encryption, and attestation routines. Key results include:

System / Paper	Benchmark	Overhead vs. Baseline	Source
Arca	CPU, threads	Near-native (SGX), +10–30% I/O	(Lu et al., 3 Jan 2026)
TCX	SPEC2017 (C/C++)	+5.8%	(Brasser et al., 2022)
CoCo	EDA workload	+7.13% (bare metal), +2.05% (VM)	(Ye et al., 2024)
dstack-OS	VM startup	+6%	(Zhou et al., 15 Sep 2025)
Parma	SPEC CPU2017	+13.4%	(Johnson et al., 2023)
EBCC	Keystone (light)	+250% (cold), +250% (warm)	(Lu et al., 13 May 2026)
dstack-capsule	Pod startup	6.25 s (dstack) vs. 8.85 s (CoCo)	(Yang et al., 2 Jun 2026)

Absolute and relative overheads are typically lowest for VM-based approaches on I/O-bound workloads (<1%–10%), with overheads as low as 0.23% attributable to FS or network encryption sidecars (Ye et al., 2024). Latency and memory use are dominated by the per-VM or per-enclave granularity; systems that amortize the TEE context (Pod-level attestation in dstack-capsule) achieve 2 MB/Pod incremental memory versus ~2 GB in per-VM (CoCo) models (Yang et al., 2 Jun 2026). OCI-compatible frameworks (EBCC) incur higher cold start penalties due to multi-layer mediation.

5. Taxonomy of Vulnerabilities and Mitigation Strategies

Empirical analysis (e.g., TBouncer fuzzer, code review) surfaces critical attack surfaces:

• Information Leakage: File-system access patterns, metadata, and traffic can leak even when data is encrypted, unless sidecar encryption or block-level obfuscation are enforced (Liu et al., 28 Aug 2025).
• Rollback/Replay Attacks: Weaknesses in persistent state freshness (e.g., lack of monotonic counters) can allow replay of prior states; only strict measurement and attestation of state blobs, together with externalized counters or verified Merkle-trees, limit this attack (Zhou et al., 15 Sep 2025, Johnson et al., 2023).
• Denial of Service: Resource exhaustion, driver deadlocks, or malformed requests (e.g., VirtIO descriptors) can crash or hang the TEE. This remains an open challenge since TEEs offer limited resource throttling (Liu et al., 28 Aug 2025).
• Iago Attacks: Malicious host kernels can manipulate syscall return values, causing subtle integrity breaches. In-enclave sanitization, strict API minimization, and formal interface attestation are required (Liu et al., 28 Aug 2025, Liu et al., 2021).
• Side Channels: Most frameworks document, but do not fully mitigate, microarchitectural and timing side-channels. Some present partial defenses via in-enclave scheduling or resource padding but leave cache and page-fault attacks as future work (Liu et al., 2021).

Mitigation strategies synthesized in the literature include: aggressive minimization and sanitization of Ocalls, splitting interface surfaces (host-side vs. owner-controlled), integrating integrity-protected storage/networking stacks into the TEE, and declaring measured trust boundaries and policy surfaces.

6. Emerging Trends and Open Problems

Ongoing research and deployment efforts are converging toward several directions:

• Standardized, Attestation-Driven Workflows: Attested policies (e.g., Rego/OPA), measured metadata, and fine-grained splitting of sensitive and non-sensitive orchestration functions promise more flexible but verifiable container operations (Johnson et al., 2023, Yang et al., 2 Jun 2026).
• Cross-TEE and Cross-Cloud Migration: Techniques for abstraction and key derivation (dstack-KMS, dstack-OS) enable seamless movement of containers among heterogeneous TEEs, supporting scalable Web3 and multi-cloud infrastructure (Zhou et al., 15 Sep 2025).
• Zero-Trust and Blockchain Anchoring: Decentralized key management, blockchain-governed code policies, and transparent, auditable domain management provide trustless guarantees, particularly critical for distributed or censorship-resistant applications (Zhou et al., 15 Sep 2025).
• Serverless and Multi-Tenant Enclaves: Emerging trends point toward in-enclave multi-process sandboxing (e.g., SFI-hardened serverless frameworks) and data-capsule abstractions for policy-compliant multi-party computations (Liu et al., 28 Aug 2025).
• Kubernetes and Service Mesh Integration: Confidential Pods with resource amortization (dstack-capsule), service-mesh–based mTLS enforcement, and operator-integrated confidential workflows are bridging the usability gap for large-scale production deployments (Yang et al., 2 Jun 2026, Ye et al., 2024).

Key open challenges include ongoing side-channel resilience, formal verification of minimized TEE runtimes, richer but secure I/O models inside TEEs, GPU and advanced device passthrough, and detection/recovery from latent TEE hardware vulnerabilities.

7. Comparative Landscape and Best Practices Synthesis

A comparison of leading PCC frameworks elucidates the design continuum:

Architecture	Granularity	Isolation Modalities	TCB Footprint	Attestation Surface	Overhead
Arca	Container	1 enclave/VM per app	5–10 K LoC/agent	App code + agent	~native/+10% I/O
CoCo/TCX	Pod (VM)	VM per group	Guest OS + agent	VM, app image, config	5–8% (C/C++ workload)
dstack-capsule	Pod (<VM)	Shared CVM, per-Pod att	6.9 kLoC agent	Spec hash + platform	2 MB/Pod incr. mem
Parma	Pod (VM)	SEV-SNP UVM	Guest OS + agent	Guest, agent, policy	13–26% CPU2017
EBCC	Stage/comp.	TEE dispatch by comp.	Host runtime ~3 KLoC	Per-stage evidence	Variable (high)

Best practices distilled include:

• Confine the TCB to only what is strictly necessary for each confidential workload (minimal in-TEE logic, keep orchestrators out) (Lu et al., 3 Jan 2026).
• Rely on attestation for every measured artifact—code, policy, configuration, secrets—never trust host-supplied operations without explicit measurement (Johnson et al., 2023, Liu et al., 28 Aug 2025).
• Utilize abstraction layers to maximize portability, decoupling upper application code from TEE specifics (Zhou et al., 15 Sep 2025, Lu et al., 13 May 2026).
• Always minimize and sanitize all interfaces crossing the trust boundary; employ layered defense at disk, network, runtime, and API levels (Liu et al., 28 Aug 2025, Yang et al., 2 Jun 2026).
• Document the precise guarantees and excluded risks (e.g., side-channels), enabling users and auditors to align risk appetite with operational context.

Portable confidential containers are now the established substrate for confidential computing in cloud-native, HPC, and Web3 scenarios, blending manageability, strong cryptographic security, and operational portability across an expanding portfolio of hardware and platform substrates. Continued research into formal verification, dynamic attestation, and cross-TEE protocol unification will further mature the field.