Un fork de Kata Containers elimina el 60% del código para reducir su superficie de ataque

Un fork de Kata Containers ha adelgazado el proyecto alrededor de un 60%: su autor ha borrado todo el código que no hace falta para ejecutar cargas x86_64 de Kubernetes dentro de una VM de Firecracker, y ha dejado el runtime del host en 13.500 líneas y el agente en 8.100. El objetivo no era el rendimiento, era la superficie de ataque.

El código está en srcreigh/kata-containers. Toda la edición salió de Codex CLI; el autor escribió el post a mano, pero cada cambio lo aplicó un agente. Las modificaciones no son solo borrado: al quitar código aparecieron fallos que hubo que arreglar. La validación se hizo en su clúster de homelab, con varias cargas de Kubernetes no confiables corriendo en Firecracker a través de Kata.

Por qué Firecracker no basta

El punto de partida es que una VM no es, por sí sola, un límite de seguridad. El autor cita los experimentos publicados por Artem Dinaburg el 26 de agosto de 2026, en los que se rompe el aislamiento de qemu hacia un host Debian en tres ocasiones distintas. Firecracker sí se cuenta entre los pocos hipervisores Linux seguros, pero meter Kubernetes dentro abre canales nuevos: el agente que vive en la VM recibe RPCs del host y el invitado puede contestar con datos malformados. El host queda expuesto de formas que un Firecracker pelado no tiene. Además, Firecracker no ofrece hoy manera de correr cargas basadas en contenedores; firecracker-containerd sigue en desarrollo, sin soporte de Kubernetes.

Ese hueco es la excusa del fork: no había ningún proyecto cuyo objetivo declarado fuera una integración Kubernetes-Firecracker con superficie mínima.

Cómo lo hizo

Primero, pasadas con Astra en modo Medio/Alto para borrar lo que no necesitan sus cargas. Cayeron el soporte de otras VMs, todo el runtime legacy en Go y la carga de módulos de kernel del agente. Después vinieron pasadas más quirúrgicas sobre el código del runtime que parsea datos producidos por el agente; ahí aparecieron casos en los que una respuesta malformada podía provocar un panic en el shim. Tuvo que frenar a la herramienta cuando se puso a reproducir bugs. También volvió a añadir cosas que había quitado de más, como volumeDevices. La última pasada, con Astra Ultra, auditó línea a línea durante unos 55 minutos y entre otras cosas encontró un deadlock en la inicialización de red.

Los avisos del autor van en la misma línea: no es profesional de seguridad, no ha auditado el código, no se compromete a mantener el fork sincronizado con el upstream, no hay instrucciones de instalación y no se ha probado en producción. Dice que quiere subir cambios al proyecto original, pero que no será pronto, o nunca.

Queda como un experimento y no como un producto, y eso limita lo que se puede hacer con él hoy. Pero deja una pregunta incómoda para quien aísla cargas con Kata: cuánto del runtime se usa de verdad y cuánto solo está ahí esperando a que alguien lo alcance.