Live data from Hacker News

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

github.com

41–50 of 58 posts

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

#41
post #20

Why do I need this if I already have containers and k8s for running agents?

It is well known that containers do not provide you safe isolation. It is not their purpose. They share kernel and page cache with the host. Any kernel exploit gives to someone in a container potential root control of the host (see DirtyPipe, DirtyCow). That's why you need VM-level isolation.

today i'm one of the lucky 10k https://xkcd.com/1053/

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

#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

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

#45
post #36

what does Katakana add on top of Kata?

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.

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

#46
post #20

Earlier quoted context omitted.

It is well known that containers do not provide you safe isolation. It is not their purpose. They share kernel and page cache with the host. Any kernel exploit gives to someone in a container potential root control of the host (see DirtyPipe, DirtyCow). That's why you need VM-level isolation.

today i'm one of the lucky 10k https://xkcd.com/1053/

Lucky you! And lucky me for sharing the info :)

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

#48
post #37

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.

What about this: https://github.com/apple/container

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.

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

#49
post #33
post #11

Earlier quoted context omitted.

True! GCP does. I haven't tested it yet. I didn't know D.O does. If anyone knows others, I'm interested too!

We (NanoVMs) can run (both unikernel and normal linux) virtualized workloads on plain old ec2 instances (eg: t2.small).

Interesting, thanks for sharing!

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

#50
post #38

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.

https://rstrict.cloud/ is a CLI built in Rust on top of the Landlock API for the Linux kernel. It lets you narrow the permission scope of an executable using simple command line wrappers.

Thanks, will study that one too!
Post reply on HN