What
Write docs/firecracker.md documenting how to run OpenAB agents inside Firecracker microVMs via Kata Containers on K3s.
Why
OpenAB's current sandbox model uses K8s pod isolation (container-level, shared kernel). Firecracker provides microVM isolation (independent kernel per agent), which is the strongest isolation boundary available without dedicated hardware.
This is relevant for users who want defense against kernel exploits — the agent gets its own kernel, so even a kernel-level escape stays contained.
Content outline
- Prerequisites (x86_64 with KVM / Intel VT-x, K3s)
- Install Kata Containers with Firecracker backend on K3s
- Create
kata-fc RuntimeClass
- Configure OAB Helm chart to use the RuntimeClass
- Resource considerations (~30-50MB overhead per microVM)
- Comparison: runc vs Kata/Firecracker isolation boundaries
- Tested on: Intel N100 mini PC + Ubuntu
Context
Discussion: OpenShell (NVIDIA) provides container + Landlock + L7 proxy isolation but still shares the host kernel. Firecracker is the path to true kernel-level isolation while staying on K3s (no infra change needed for OAB — just add a RuntimeClass).
What
Write
docs/firecracker.mddocumenting how to run OpenAB agents inside Firecracker microVMs via Kata Containers on K3s.Why
OpenAB's current sandbox model uses K8s pod isolation (container-level, shared kernel). Firecracker provides microVM isolation (independent kernel per agent), which is the strongest isolation boundary available without dedicated hardware.
This is relevant for users who want defense against kernel exploits — the agent gets its own kernel, so even a kernel-level escape stays contained.
Content outline
kata-fcRuntimeClassContext
Discussion: OpenShell (NVIDIA) provides container + Landlock + L7 proxy isolation but still shares the host kernel. Firecracker is the path to true kernel-level isolation while staying on K3s (no infra change needed for OAB — just add a RuntimeClass).