The Five Big Problems with Confidential Containers

### Overview Presented by Christopher, this talk explores the challenges encountered in bringing confidential computing guarantees to containerized environments via the CNCF sandbox project, Confidential Containers (built on Kata Containers). While cloud computing isolates the host from malicious containers, traditional environments allow host administrators to inspect memory, state, and container data. Confidential computing leverages hardware-based trusted execution environments (TEEs) and encrypted memory to protect guest workloads from an untrusted host. However, adapting this model to containers introduces five major challenges: attestation complexity, performance and deduplication overheads, image downloading architecture, access control splits in Kubernetes, and debuggability.

### Key Topics & Architecture Confidential Containers builds upon Kata Containers' architecture, which wraps containers inside lightweight virtual machines managed by hypervisors via `shimv2` and a guest Kata agent. Achieving confidential execution requires hardware cryptographic support across diverse hardware architectures, including AMD SEV/SEV-ES/SEV-SNP, Intel TDX, IBM s390 Secure Execution, Power PEF, and ARM CCA. The speaker outlines the separation of three operational zones: the trusted platform (hardware cryptography), the untrusted host (providing compute, storage, and networking without visibility), and the tenant/TEE.

### Technical Details & The Five Problems 1. **Attestation Complexity**: Workloads must prove their integrity to an Attestation Service (AS) and Key Broker Service (KBS) before sensitive keys and secrets are released. The landscape is fragmented by competing approaches (pre-attestation vs. post-attestation, IETF RATS, virtual TPM research, and vendor-specific implementations). The project requires standardized protocols and an abstraction layer to hide hardware differences from user space. 2. **Performance and Deduplication Loss**: While raw CPU runtime overhead is generally manageable (often within 5%), confidentiality breaks core hypervisor optimizations. Encrypted memory prevents Same-Page Merging (KSM), encrypted disks prevent block deduplication, and encrypted images eliminate multi-tenant container layer sharing. 3. **Image Download Architecture**: Traditionally, container runtimes pull images on the untrusted host. To protect confidentiality, image pulling must move inside the guest VM to transient encrypted storage. Integrating this into containerd required architectural proposals that were initially rejected for broader redesigns. Additionally, while tools like Nydus provide file-based image caching, encrypted containers need block-level caching (via dm-crypt, dm-verity, and nbdkit) and image splitting tools (such as Sergio Lopez's `oci-to-cw`) to cache blocks on the host while keeping secrets guest-side. 4. **Access Control in Kubernetes**: Kubernetes APIs were designed assuming dual-party trust (user and cluster/host). Confidential containers introduce a three-party model (tenant, host, hardware platform). Existing APIs mingle host infrastructure actions with tenant operations. For instance, log retrieval previously handled by the host now requires tenant authentication and end-to-end encryption, necessitating a split API mechanism. 5. **Debuggability vs. Confidentiality**: In a confidential container, host-level introspection, core dumping, and unencrypted panic logging are strictly prevented by hardware guarantees. If a kernel panic occurs, logs cannot simply be leaked to the host console without breaking security guarantees.

### Takeaways & Q&A Insights The first release of Confidential Containers is approaching, but practical, uniform attestation and fully split Kubernetes access control remain ongoing efforts. During the Q&A, the speaker noted that virtual GPU (vGPU) confidential computing remains largely unresolved due to inverted trust models and lack of encryption support in shared mechanisms. Furthermore, traditional Virtio-fs shared filesystems are avoided in favor of block devices (virtio-blk) with dm-crypt to prevent host-side metadata leakage and traffic pattern analysis.