Update: Katakate now supports ARM architecture (on Linux) thanks to a PR merged from Katakate's first external GitHub contributor: @spullara. Thank you!

Thanks! I'll review Arrakis and come back. E2B is often considered harder to setup and less AI engineers friendly for direct stack contributions, as Katakate is the only alternative fully implemented in Python (core modules, Typer CLI, FastAPI, Python SDK).

Our native K8s support and exposition of K8s API also makes it friendly to devops.

Finally, our deploy/infra stack is lean and tightly fits in a single Ansible playbook, which makes it easy to understand and contribute to, letting you rapidly gain full understanding and ownership of the stack.

Thanks! Yes: Katakate provides much stronger isolation, since it uses hardware virtualization (via Kata Containers and Firecracker) while gVisor relies purely on software sandboxing in user space.

gVisor isolates containers by intercepting system calls in a user-space kernel, so it can still be vulnerable to sandbox escape via gVisor bugs, though not directly through Linux kernel exploits (since gVisor doesn’t expose the host kernel to the container).

Katakate also provides more than isolation: it offers orchestration through Kubernetes (K3s)

You could create a gVisor RuntimeClass in Kubernetes to orchestrate gVisor sandboxes, but that would require extra setup.

Thanks for sharing, adding it to my list.

Very cool! Apple containers run on Apple ARM so it's complimentary to my stack which doesn't support ARM yet (but soon will when extending to Qemu which supports ARM). Thanks for sharing!

Thanks, will study that one too!

Very cool one. That's dedicated to Apple ARM which I don't currently support so the two are complimentary. Apple containers shares some primitives with Kata. I'll investigate if it's possible to use Apple containers as a VMM inside Kata, or creating an Apple Containers runtime class in Kubernetes. If either is possible, we could then potentially use Apple containers as a backend in Katakate. I need more time to study that.

Thanks, I'll review that one too and compare.

Katakate is built on top of Kata, and sets up a stack combining Kubernetes (K3s), Kata, Firecracker, and devmapper snapshotter for thin pool provisioning. Combining these tools together is highly non-trivial and can be a headache for many, especially for AI engs who are often more comfortable with Python workflows. The stack gets deployed with an Ansible playbook. It implements a CLI, API and Python SDK to make it super easy to use. A lot of defense in depth settings are also baked-in so that you don't need to understand those systems at a low level to get a secure setup.

That's a config example.

Yes, blocking DNS exfiltration requires DNS filtering at cluster level. This is what will be added with the Cilium integration which is top-3 on the roadmap (top of readme).

DNS resolution is required for basic Kubernetes functionality and hostname resolution within the cluster.

That's said explicitly in several places in the docs: "DNS to CoreDNS allowed"

One thing I could do is make it exposed in config, to allow the user to block all DNS resolutions until Cilium is integrated. LMK if desired!

> One thing I could do is make it exposed in config, to allow the user to block all DNS resolutions until Cilium is integrated. LMK if desired!

Yes, but it's not great for it to be an optional config option. Trivially easy to use data exfiltration methods shouldn't be possible at all in a tool like this, let alone enabled by default.

I want to recommend ppl to try this out and not have to tell them about the 5 different options they need to configure in order for it to actually be safe. It ends up defeating the purpose of the tool in my opinion.

Some use cases will require mitmproxy whitelists as well, eg default deny pulling container image except matching the container whitelist.

As promised: https://github.com/Katakate/k7/tree/fix/no-dns-res-in-lockdo...

Will merge that in after it passes all network tests on a clean/wiped instance.

Test passed, PR merged

This is an excellent point. I moved this to #1 on the TODO list. I'll deny all DNS resolution by default until Cilium is integrated, if that passes the basic functionality tests.

I'll also add to the roadmap whilelist/deny for container pulling.

Thanks!