Secure VMs for Kubernetes: Hardening Kata containers

Yesterday, Astra was used to delete approximately 60% of Kata Containers code while still maintaining the ability to run x86_64 Kubernetes workloads in Firecracker VMs. The goal was to reduce the attack surface and make the code more easily auditable. The modified codebase now has 13.5k SLOC for the host runtime and 8.1k SLOC for the agent.

Changes were verified in the reporter's homelab cluster, which runs untrusted Kubernetes workloads in Firecracker via Kata, and caught several issues. The reporter is not a security professional, has not audited the code themselves, and does not intend to keep the fork updated with Kata upstream. There are no setup instructions, the code has not been tested in a real production setting, and no guarantees or setup instructions are offered.

This work is not intended as a solution for minimal attack surface Kubernetes-Firecracker integration, as there is currently no dedicated project for this purpose. While Firecracker is one of the only secure Linux VMs available, it is not safe to assume that a workload running inside Firecracker is inherently secure. Tools that run Kubernetes pods inside Firecracker introduce new communication channels with the guest VM, which can lead to security vulnerabilities.

One such vulnerability was demonstrated by Artem Dinaburg, who was able to break out of a qemu VM running Debian three times using GPT-5.6 Cyber. The reporter used Astra to delete code they deemed unnecessary for their workloads, which initially removed a significant portion of the code. However, some useful Kubernetes features were removed and later added back after Astra identified them as necessary for the reporter's specific use case.

Astra's analysis uncovered issues like a networking init deadlock, where a synchronous thread yield from an async context caused a deadlock. After removing some initial code, the thread was launched before it was ready, leading to the deadlock.