Hacker News Reader

Comment by McScrooge | Hacker News Reader

https://docker.github.io/docker-agent/configuration/sandbox/

If, like me, you couldn't find any security-related info on the linked page.

Docker Agent is a harness. There is a sandbox mode that can be used to run it in docker sandbox (a VM, not a container). If you don't use sandbox mode then I assume it is running in a container.

If you don't want to use their harness then you wouldn't use docker agent and instead use their `sbx` cli to run the harness of your choice (claude, codex, pi, etc).

I think it will be great if Docker can get people used to using secure VMs. I am developing a similar project (still a work in progress): https://github.com/gregwebs/agent-vm

I've found sbx to be very helpful. really like the sentinel value wrapper they have going so you can add secrets but the model can't see them. Outbound calls get looked up by sentinel value and the real one goes out to whatever API you're auth'ing too. There's other features but just having claude run in a sandbox and easily see what it does and doesn't have access to has been great.

I just wish sharing whitelisted domains between sandboxes were easier or more intuitive. Last time I tried doing this with sbx I was handling their yaml files by hand.

# Allow network access globally (all sandboxes) sbx policy allow network <domain>[,<domain>…]

# Remove a global network rule sbx policy rm network --resource <host>

# Remove a sandbox-specific network rule sbx policy rm network --sandbox <sandbox> --resource <host>

Interesting, we're doing something similar, but unlike yours, we focus on the server side for teams. We even wrote a blog post about this Docker and Apple container idea. https://virtainer.io/blog/docker-sandboxes-and-virtainer-app...

i remember going through the entire docs of docker sandbox and there was not one mention of attack vectors. did they fix that?

Reply on news.ycombinator.com