TEE-in-Container Architecture

• TEE-in-Container Architecture is a secure approach that integrates hardware-based TEEs with container orchestration to provide runtime confidentiality and minimize the trusted computing base.
• It employs minimal in-TEE code, robust attestation protocols, and cross-TEE abstractions to isolate sensitive workloads while maintaining performance efficiencies.
• Leveraging technologies like Intel SGX, TDX, and AMD SEV, the architecture achieves near-native throughput and scalability for cloud-native deployments.

A TEE-in-Container architecture integrates hardware-based Trusted Execution Environments (TEEs) with cloud-native container resource management, providing strong runtime confidentiality and integrity for container workloads while maintaining scalability and agility. This approach encapsulates sensitive application logic inside a TEE—such as Intel SGX, Intel TDX, or AMD SEV—while keeping the orchestration, scheduling, and management logic outside the hardware trust boundary. By aligning trust domains with container boundaries, these architectures minimize the Trusted Computing Base (TCB), confine the impact of compromise, and avoid performance bottlenecks and resource bloat inherent in legacy “Container-in-TEE” models (Lee et al., 2024, Lu et al., 3 Jan 2026, Brasser et al., 2022).

1. Architectural Principles and Trust Model

TEE-in-Container architectures seek to reconcile two dominant trends in secure cloud computing: (1) container-based process isolation and resource management, and (2) hardware-enforced isolation for confidential workloads. In this model, each sensitive container is bound to its own instance of a hardware TEE, such as an SGX enclave or SEV- or TDX-backed VM, with the orchestration plane (Kubernetes, Docker, containerd) remaining outside the trusted perimeter (Lee et al., 2024, Lu et al., 3 Jan 2026, Brasser et al., 2022).

The security model assumes a maximally powerful adversary controlling the host kernel, container runtime, hypervisor, and all networking/storage interfaces. Only the CPU TEE hardware, its attestation process, and the initial code/data inside each secure enclave/VM are trusted. Lateral movement is prevented by keeping each container/workload isolated in its independent TEE domain, with no shared keying or memory regions. Orchestration and management, including scheduling and image provisioning, are explicitly excluded from the TCB.

2. Core Mechanisms and Implementation Techniques

Minimal TCB and Trust Alignment

A fundamental principle is minimizing the in-TEE code: only the sensitive application logic, cryptographic operations, and a thin LibOS or WASM runtime are permitted inside the enclave, while all other infrastructure is handled by untrusted host software (Lu et al., 3 Jan 2026, Lee et al., 2024, Brasser et al., 2022). This sharply contrasts with “Container-in-TEE” designs (e.g., CoCo/Kata), which enclose the entire container runtime and OS stack within the enclave or VM, resulting in TCB size inflation and additional attack surface (Lu et al., 3 Jan 2026).

Formally, the TCB reduction in Arca is quantified as follows: $$|TCB_{\mathrm{Arca}}| \approx 105\,\text{KLoC} \qquad |TCB_{\mathrm{CoCo}}| \approx 475\,\text{KLoC}$$ indicating a 78% reduction in TCB complexity (Lu et al., 3 Jan 2026).

Secure Hardware Isolation and Attestation Flows

TEE-in-Container frameworks support multiple hardware isolation backends:

• Intel SGX: Each container process launches an enclave using ECREATE/EADD/EINIT flows, with the enclave measurement (MRENCLAVE) used for remote attestation and sealed key derivation. When sharing enclaves across containers (TEEMATE), enclave page cache (EPC) pages and Thread Control Structures (TCS) can be aliased and reassigned to map host containers onto a single physical enclave (Lee et al., 2024).
• Intel TDX/AMD SEV: Containers run as confidential micro-VMs. Each VM has hardware-encrypted memory, unique measurement, and independently attested launch protocols (TDREPORT for TDX; PSPREPORT for SEV). dm-crypt/dm-verity ensure persistent image confidentiality and integrity, and mutual TLS is used for secure channel provisioning and secret injection (Lu et al., 3 Jan 2026, Brasser et al., 2022, Johnson et al., 2023).
• Cross-TEE Abstractions: Some solutions (e.g., Enarx) provide a universal loader, abstracting away TEE vendor differences and permitting multi-backend deployments (Paju et al., 2023).

Memory and Thread Isolation (TEEMATE Primitives)

TEEMATE demonstrates that SGX enclaves are not inherently process-bound. By exposing primitives for (i) EPC aliasing—mapping the same physical EPC frames into multiple container page tables, and (ii) dynamic TCS allocation—distributing thread control structures among containerized workloads, TEEMATE enables sharing a single enclave among multiple logical containers while maintaining the illusion of per-container isolation. The resulting aggregate secure memory usage shifts from $M_\text{total} = N\cdot M_e$ to $M_\text{shared} = M_e + \varepsilon$ ($\varepsilon$ for per-container metadata), achieving substantial reductions in resource overhead (Lee et al., 2024).

3. Container Lifecycle, Orchestration, and Integration

Provisioning a confidential container involves:

• Scheduling container workload on the host orchestrator (e.g., Kubernetes).
• Creating an isolated enclave or confidential VM per container via the TEE runtime or host agent (for process-based TEEs) or QEMU/TDX/SEV for VM-based TEEs.
• Performing remote attestation, typically involving a hardware-rooted measurement/quote and verification against a trusted policy.
• Setting up a secure channel for key injection and secret provisioning.
• Running the workload, with LibOS or WASM runtime confining the sensitive compute.
• Handling container teardown and secure resource destruction upon exit (Lu et al., 3 Jan 2026, Brasser et al., 2022, Lee et al., 2024).

Table: Comparison of TEE-in-Container Platforms

Platform	TEE Kind	TCB Layering	Notable Mechanisms
Arca	SGX/TDX/SEV	Per-container enclave/VM	Minimal TCB, split agent/app
TEEMATE	SGX	Shared enclave	EPC aliasing, TCS rebinding
TCX	SEV	Per-container micro-VM	Root VM for attestation

(Lu et al., 3 Jan 2026, Lee et al., 2024, Brasser et al., 2022)

4. Performance Characteristics

Eliminating container runtime code from the TCB and avoiding full-stack VMs yields near-native performance in most workloads. For SGX- and TDX-based deployments, Arca consistently achieves 95–98% of native throughput and 15–22% speedups over legacy Container-in-TEE platforms. On AMD SEV, additional indirection for image and key management yields a geometric-mean slowdown of 5.77% over native, with the VM-launch and secret-injection protocols adding only trivial overhead (Lu et al., 3 Jan 2026, Brasser et al., 2022).

TEEMATE’s enclave-sharing model further improves efficiency: for serverless or fork-heavy apps, cold-start latency is reduced 4.5–7× and EPC usage up to 5× by eliminating redundant enclave instantiation and leveraging shared secure memory (Lee et al., 2024). Fork-snapshot scenarios (Redis) demonstrate up to 1000× speedup over per-container enclave models.

5. Security Analysis, Common Pitfalls, and Mitigation

Trust Boundary Definition

TEE-in-Container frameworks must mediate all flows across the enclave-host or VM-host boundary, ensuring that confidentiality (no more data is leaked than the intended abstraction) and integrity (no invalid host influence over in-TEE state) are preserved (Liu et al., 28 Aug 2025, Liu et al., 2021).

Observed Vulnerabilities

Studies on real-world TEE-in-Container implementations have identified critical weaknesses:

• Incomplete Ocall/Ecall Mediation: Many systems forward syscalls naively, exposing high-bandwidth covert channels or enabling Iago return-value attacks (Liu et al., 2021, Liu et al., 28 Aug 2025).
• File I/O Metadata Leakage: Host-observable filenames and offsets from enclave OCALLs enable fine-grained access pattern inference (Liu et al., 28 Aug 2025).
• Rollback and Replay Attacks: Weaknesses in persistent storage freshness enable state rollback, violating integrity (Liu et al., 28 Aug 2025).
• Denial-of-Service and Resource Abuse: Missing in-enclave resource accounting can exhaust host resources (Liu et al., 28 Aug 2025).
• Large TCB in Legacy Designs: Monolithic in-TEE runtime inclusion increases the attack surface and complexity, reducing verifiability (Lu et al., 3 Jan 2026).
• Misleading Documentation: Claimed security guarantees often do not reflect actual protection coverage (Liu et al., 2021).

Best Practices

Research consensus points to five principal hardening actions:

1. Minimize and strictly mediate all host-enclave interfaces, using syscall whitelists and rigorous argument/result checks.
2. Employ atomic, integrity-protected I/O (e.g., Merkle-tree backed block devices for SEV; journaling within the LibOS for SGX).
3. Enforce per-container hardware trust domains, eliminating cross-container shared keying or memory spaces.
4. Establish a robust attestation and key-injection protocol gating sensitive operations.
5. Provide transparent documentation of the trust boundary, threat model, and guarantees (Lu et al., 3 Jan 2026, Liu et al., 2021, Liu et al., 28 Aug 2025).

6. Generalizations, Ecosystem, and Future Directions

TEE-in-Container concepts extend beyond specific hardware backends. Mechanisms analogous to EPC aliasing (SGX) or address-space sharing (SEV/TDX/CCA) exist or can be realized in other architectures by reconstructing secure page mappings and dynamically assigning compute contexts (e.g., vCPU for VM-based TEEs) (Lee et al., 2024). Kubernetes and host container ecosystems are increasingly incorporating support for confidential deployment models, integrating TEE launch and attestation flows via runtime plugins, sidecars, and custom Kubernetes resources (Paju et al., 2023, Lu et al., 3 Jan 2026). WASI-based runtimes (e.g., Enarx, Apache Teaclave) and hybrid loader models offer new trade-offs in TCB size, porting effort, and multi-TEE support.

The field is trending toward:

• Flattened runtime hierarchies (minimal in-TEE code).
• Per-container hardware isolation with strict measurement-derived keys.
• Universal attestation channels for cross-container or owner-mediated secure communication.
• Hardening of the orchestration plane, including confidential control planes and formally specified API/ABI boundaries (Liu et al., 28 Aug 2025, Liu et al., 2021, Lu et al., 3 Jan 2026).

---

Key References:

• "TEEMATE: Fast and Efficient Confidential Container using Shared Enclave" (Lee et al., 2024)
• "Arca: A Lightweight Confidential Container Architecture for Cloud-Native Environments" (Lu et al., 3 Jan 2026)
• "Trusted Container Extensions for Container-based Confidential Computing" (Brasser et al., 2022)
• "Characterizing Trust Boundary Vulnerabilities in TEE Containers" (Liu et al., 28 Aug 2025)
• "Understanding TEE Containers, Easy to Use? Hard to Trust" (Liu et al., 2021)
• "SoK: A Systematic Review of TEE Usage for Developing Trusted Applications" (Paju et al., 2023)
• "Parma: Confidential Containers via Attested Execution Policies" (Johnson et al., 2023)