Docker has introduced a sandbox feature to run AI coding agents on own's machine within an isolated environment. Running these agents directly on the host without any guardrails could cause a serious security issue as well as unexpected removal of files and network connections.
Official documentation
- https://docs.docker.com/ai/sandboxes/
- https://docs.docker.com/ai/sandboxes/architecture/
- https://docs.docker.com/ai/sandboxes/network-policies/
How the feature works
This new mechanism is a clever implementation that works as follows:
- A new docker plugin called sandbox serves as both a cli extension and a daemon.
- The daemon itself manages the sandboxes and also hosts a network proxy that the workloads within the sandboxes go through to make network egress calls.
- The sandboxes themselves are microvms launched through com.docker.krun which itself seems to be using libkrun.
- Each sandbox contains its own dockerd daemon and run its own containers workloads. It also ensures that http proxy environment variables are defined so that tools do natively know which proxy server to use for network egress connections.
- The network proxy seems to be using goproxy and has advanced capabilities like allowing / denying outgoing connections based on hostnames/ips and ports
Notes
- You can't just edit the
proxy-config.jsonfile with an editor. You have to use thedocker sandbox network proxycommand to set network egress rules which sends aPOST /network/proxyconfigto thedocker-sandbox daemon. Theproxy-config.jsonis only a reflection of the current network settings. - No default gateway set within the container running the AI coding agent. It can only route to the proxy server which means that even if an attacker tries to bypass the proxy env vars, he won't be able to route traffic externally.
-
ip route
127.0.0.0/8 dev lo scope host
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.65.0/24 dev eth0 scope link mtu 65520
192.168.65.7 dev services1 scope link
-