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

331–340 of 421 posts

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

#331

Post by cpburns2009 »

srini-docker wrote: post #298

I work at Docker. Lot of valid and useful feedback here that we're looking closely at. One correction: this isn't containers. Each session is a microVM with its own kernel on the platform's native hypervisor: Hypervisor.framework, WHP, KVM. We wrote a new VMM (not Firecracker) to make it more effective across platforms. Explained a bit more here about the architecture and why those choices were made: https://www.dock…

Do you have a strategy for secrets? Such as storing them, or using MitM to inject them (e.g., HTTP API requests)? I've used squid cache in the past, and currently use iron-proxy for this sort of feature.

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

#332

Post by cpburns2009 »

TacticalCoder wrote: post #240
pojzon wrote: post #199

Earlier quoted context omitted.

Docker containers are not enough isolation for anyone that cares about jailbreak scenarios. Only real alternative is to use microvms. My goto solution for this are apple/containers.

> Only real alternative is to use microvms. My goto solution for this are apple/containers. Why microVMs? I never ever run a container, AI harness or other, in something else than a full on VM. I could use a microVM but in any case I really don't see why I'd run a container on one of my bare metal OS: the place of a container is inside a VM (or microVM). Especially for AI harnesses where the threat of an escape is ve…

The nice thing about running a microVM like a container is the interface is relatively easy, especially if you've used containers before.

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

#333

Post by dallen33 »

tacker2000 wrote: post #325
srini-docker wrote: post #318

Earlier quoted context omitted.

Linux is available today (Ubuntu): github.com/docker/sbx-releases. Our webpage showing only brew and winget is on us. For the people upthread who asked about on customization: templates (like snapshotting a running sandbox) and kits (YAML applied at creation like install steps, files, network and credential rules, or define a new agent outright) are the supported path now. It's early but take a look here: https://doc…

Please consider adding MacPorts support. Brew is notoriously developer-unfriendly.

How so?

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

#335

Post by icedchai »

ruszki wrote: post #329
skinfaxi wrote: post #217

Earlier quoted context omitted.

The agent has no access to the secret. It has a placeholder that is replaced at a higher level. When it makes the network request the secret is substituted but that is outside of the caller's worldview.

But how? Normally the TLS handshake and encryption/decryption happen in user space. Even the kernel doesn’t know anything about it.

There is a transparent proxy installed (along with the necessary certificates on the VM.) For an example, see https://docs.microsandbox.dev/networking/tls

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

#336

Post by angry_octet »

cognitiveinline wrote: post #275
angry_octet wrote: post #239

Earlier quoted context omitted.

LLMs are great at finding 0-day, and people are rubbish at updating their containers and hosts to patch b-day. Containers have access to the kernel ABI, and as shown in the latest kernel exploits, all the memory handling surface that exposes. The virtualisation interface, offering fewer services, is significantly harder. Containers are obviously lighter than VMs, both to start and to schedule, but firecracker is pret…

Got it. 0 days are possible so throwaway containerization. You should blog about it, will help millions of developers and companies. Heck, even consult with the hyperscalers - they will be riddled with their workloads.

Who do you think created firecracker? gVisor?

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

#337

Post by venatiodecorus »

RagnarD wrote: post #151
TheqO wrote: post #115

Earlier quoted context omitted.

There are many devs that have little to no experience of Linux, like the hundreds of thousands of .Net and Java CRUD devs in enterprise companies using Windows. There is a need for a Docker desktop like GUI for this market.

Huh? https://docs.docker.com/desktop/setup/install/windows-instal... Also, WSL (Windows Subsystem for Linux) has been baked into Windows for a long time and makes it very easy to play with Linux, as does using the Hyper-V VM system. Any developer unfamiliar with Linux because they use Windows, has little excuse.

docker's sandboxes are cli only atm

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

#338

Post by bmurphy1976 »

dallen33 wrote: post #333
tacker2000 wrote: post #325

Earlier quoted context omitted.

Please consider adding MacPorts support. Brew is notoriously developer-unfriendly.

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 dev tooling and Homebrew for everything else, but with more aggressive adoption of tooling like uv an nvm I'm not sure the different really matters for me anymore.

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

#339

Post by mikesir87 »

cpburns2009 wrote: post #331
srini-docker wrote: post #298

I work at Docker. Lot of valid and useful feedback here that we're looking closely at. One correction: this isn't containers. Each session is a microVM with its own kernel on the platform's native hypervisor: Hypervisor.framework, WHP, KVM. We wrote a new VMM (not Firecracker) to make it more effective across platforms. Explained a bit more here about the architecture and why those choices were made: https://www.dock…

Do you have a strategy for secrets? Such as storing them, or using MitM to inject them (e.g., HTTP API requests)? I've used squid cache in the past, and currently use iron-proxy for this sort of feature.

The secrets are stored in the OS-specific keychain. When a sandbox starts, the network proxy injects the secret into the request (as auth headers) only when the hostname matches.

Read more about the secrets handling here - https://docs.docker.com/ai/sandboxes/security/credentials/

Kits provide the ability to also define new credentials and how to inject them into new services (connect to internal systems, etc.).

Post reply on HN