Live data from Hacker News

Show HN: Katakate – Dozens of VMs per node for safe code exec

github.com

51–58 of 58 posts

Re: Show HN: Katakate – Dozens of VMs per node for safe code exec

#51
post #32

Earlier quoted context omitted.

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 expo…

> 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 differ…

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!

Re: Show HN: Katakate – Dozens of VMs per node for safe code exec

#52

I would really like to see a good local sandboxing solution in this space, something that is truly local-first. This is especially important since many coding models / agentic builders will eventually become lightweight enough to run them on-device instead of having to buy tokens and share user data with big LLM cloud providers.

> something that is truly local-first Hey, we built coderunner[1] exactly for this purpose. It's completely local. We use apple containers for this (which are 1:1 mapped to a lightweight VM). 1. Coderunner - https://github.com/instavm/coderunner

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!

Re: Show HN: Katakate – Dozens of VMs per node for safe code exec

#53
post #44

I would really like to see a good local sandboxing solution in this space, something that is truly local-first. This is especially important since many coding models / agentic builders will eventually become lightweight enough to run them on-device instead of having to buy tokens and share user data with big LLM cloud providers.

Local-first (on Lunix), POSIX shell: https://github.com/sandbox-utils/sandbox-run

Thanks for sharing, adding it to my list.

Re: Show HN: Katakate – Dozens of VMs per node for safe code exec

#54

Looks like an interesting project. Do you have any comments on how it is different from running gVisor?

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.

Re: Show HN: Katakate – Dozens of VMs per node for safe code exec

#55

Great project. There's been multiple approaches/tools in the space(top of my head I can think of e2b, arrakis, claude's new tool). how is this different?

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.

Re: Show HN: Katakate – Dozens of VMs per node for safe code exec

#56
post #32

Earlier quoted context omitted.

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 expo…

> 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 differ…

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.

Re: Show HN: Katakate – Dozens of VMs per node for safe code exec

#57
post #56

Earlier quoted context omitted.

> 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 differ…

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
Post reply on HN