Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker Sandboxes – Disposable, isolated sandboxes for AI agents

docker.com

Post reply on HN
Print view View original

411–420 of 421 posts

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#411

Post by codethief »

figmert wrote: post #403
codethief wrote: post #192

Earlier quoted context omitted.

Yes, pretty much, except for one detail: > That runs the codex OCI in a qemu microvm. AFAIU it's actually the other way around: krun spawns a libkrun-based (not QEMU-based) VM inside a crun container. Source: https://github.com/libkrun/libkrun/discussions/538#discussio... So with your solution you get the additional security benefit of containerizing the hypervisor on the host.

Once you have a vm, the container provides next to no additional security benefits. It's just unnecessary overhead at that point.

That's not correct. Virtio devices have different security properties and many of them expose the host system to considerable risks. Using containerization on the host is one way to limit the latter. See e.g. https://github.com/libkrun/libkrun/#security-model for more details.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#412

Post by codethief »

akdev1l wrote: post #198
codethief wrote: post #191

Earlier quoted context omitted.

> exactly this This is nowhere near "exactly this". Docker Sandboxes uses micro VMs, you just use regular containers which have completely different security properties.

podman run --annotation=run.oci.handler=krun -dp 8080:8080 -t --rm server-without-wasm

Yes, you can run Podman with different OCI runtimes, in the same way as you can run Docker with different OCI runtimes, and some of these OCI runtimes are microVM-based.

This is not what the person I was responding to is doing, though.

As for differences between the krun OCI runtime and Docker Sandbox (which also uses libkrun), let's please continue the discussion here: https://news.ycombinator.com/item?id=49240662 .

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#413

Post by codethief »

akdev1l wrote: post #196
codethief wrote: post #194

To everyone sharing their favorite container-based sandboxing solution: Docker Sandbox does not use containers for isolation. It spawns the workload in a libkrun-based micro VM, which has vastly different security properties.

Do you mean like Podman has supported for years…? eg: https://josecastillolema.github.io/podman-wasm-libkrun/#libk...

Do you mean like Docker has supported for years…? (Just configure krun as Docker's OCI runtime.)

Obviously, there's a reason why Docker released Docker Sandbox as a separate product:

- Barely anyone bothers to configure Docker/Podman with a different OCI runtime like krun. Heck, most people don't even know about OCI runtimes in the first place. Case in point: Most people here in this HN discussion are proposing using "standard" containers (with the default OCI runtime) for sandboxing. This is what I was trying to get at.

- A sandbox for agent needs tighter network control.

As for differences between the krun OCI runtime and Docker Sandbox (which also uses libkrun), let's please continue the discussion here: https://news.ycombinator.com/item?id=49240662 .

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#414

Post by runtime_lens »

nezhar wrote: post #25
runtime_lens wrote: post #13

TO me, that's the important distinction: sandboxing limits what the agent can do but it doesn't necessarily enforce that the agent must run inside the sandbox. You need a separate control layer to enforce that boundary.

You design the sandbox so the agent starts in that layer. The next thing you can do is to limit the network access, this is what I'm working on right now. Or do you mean something else?

[dead]

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#415

Post by jbverschoor »

exographicskip wrote: post #382
bradgessler wrote: post #373

Earlier quoted context omitted.

I'd like to see real numbers that compare Docker Desktop for macOS before microVMs to post-microVMs. I stopped using Docker on macOS because host file system performance was so slow, even with all of the caching hacks piled on top of it, that it made the whole thing effectively unusable for development. Directionally the post shared sounds great, but it seems "too good to be true" that we'd have a performant microVM…

Same. Been using orbstack for a couple years now

I wrote https://github.com/jrz/container-shell which I use daily for both claude and other things. Compatible with Orbstack

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#416

Post by codethief »

rusch wrote: post #58

The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders. I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in. Closest open source I have seen is https://earendil-works.github.io/gondol…

> Does anyone have a better alternative?

Not necessarily better but OpenSandbox[0] by Alibaba seems similar.

[0]: https://github.com/alibaba/OpenSandbox

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#418

Post by kstenerud »

westurner wrote: post #278
kstenerud wrote: post #227

Earlier quoted context omitted.

I wrote one that has both of those: yoloAI (MIT, Go, single binary, no login). https://github.com/kstenerud/yoloai Outbound firewall is `--network-isolated`: egress is denied except the agent's own API endpoints plus domains you allow, enforced sandbox-side (working on host-side enforcement now). `--network-none` if you want nothing. Credential brokering works the way you describe (currently Claude-only, I'll add mor…

> yoloAI copies your worktree instead of mounting it Cloudflare/artifact-fs does lazy shallow git clones with a FUSE filesystem. https://github.com/cloudflare/artifact-fs Would that be faster? Re: sandboxing methods like Clawk, Amla sandbox, bwrap, agentvm, ARM64 MTE with wasmtime-mte: https://news.ycombinator.com/item?id=48893850 A few months ago now I started adding seccomp sandboxing to jinja2rs and then liboverla…

[dead]

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#419

Post by theshrike79 »

bmurphy1976 wrote: post #338
dallen33 wrote: post #333

Earlier quoted context omitted.

How so?

The parent didn't go into any detail. I can. Homebrew has a history of ripping out your foundation underneath you. One day you are on Python 3.8, then next day you are on Python 3.10 and all your packages are broken. MacPorts doesn't do that. Now, whether you should you be using the Homebrew Python is a completely different question. YMMV for other platforms managed via Homebrew. I've traditionally used MacPorts for…

I use mise for dev tooling, that way I can have the exact correct version for every project.

Python through brew is the one I expect to be the latest one I use for one-off scripts.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#420

Post by globular-toast »

mihaelm wrote: post #120
globular-toast wrote: post #102

Earlier quoted context omitted.

Not sure what you mean by "just". Containerisation is generally understood to mean something like what Docker does, which includes sandboxing but a whole lot more on top, like image management etc. Bubblewrap is just sandboxing without the rest of containerisation.

Docker Sandboxes is using microVMs, not containerization.

That's an implementation detail. They do that because less capable OSes don't have direct support for sandboxes.
Post reply on HN