Docker 沙箱 – 为 AI 代理提供一次性、隔离的沙箱

原文 ↗ Hacker News 讨论 ↗

Docker 新推出的 Sandboxes 功能旨在让 AI 编码代理运行在一次性 microVM 中，并配备出站防火墙和凭据注入，这样不受信任的工具就无法自由访问开发者机器或密钥。评论者欢迎它比传统容器更强的隔离，但强烈批评强制 Docker 登录、闭源工具以及有限的 Linux 支持，认为这削弱了信任和长期可行性。许多人指出，围绕 VM 和容器的开源沙箱生态正在增长，其中一些人更愿意自己“vibecode”出适配特定工作流和威胁模型的解决方案。

Docker Sandboxes 实际是什么

  • 多位评论者澄清，这不是普通的 Docker 容器方案。
  • 每个代理/会话都运行在宿主机虚拟化层（Hypervisor.framework、WHP、KVM）上的一个 microVM 中（类似 libkrun，拥有自己的内核）。
  • 这比普通容器提供更强的隔离，并且允许代理在沙箱内运行 Docker，而不会危及宿主机。

安全模型：VM、容器与操作系统沙箱

  • 许多人认为，不受信任的 AI 代理不应该与宿主机共享内核；相比基于 cgroups 的容器，更倾向于使用 VM/microVM。
  • 也有人反驳说，对大多数开发者而言，非特权容器已经“足够好”，逃逸主要涉及 0-day 和糟糕的配置。
  • 一些人采用分层防御：VM + 其中再运行容器 + 出站防火墙 + 受限挂载。
  • 讨论还在进行中，bubblewrap、nono、gVisor、libkrun、Kata Containers、Incus/LXC、Flatpak 等都被视为可替代的沙箱原语。

登录要求、闭源与治理

  • 对本地开发工具强制要求 Docker 登录，广受反感。
  • 有人认为这是糟糕的用户体验，并担心未来会有付费墙/限制或突然变卦。
  • 还有一个企业版“AI Governance”产品，用于集中强制执行沙箱策略。

凭据注入与网络控制

  • 在代理边界进行凭据注入（密钥存储在宿主机钥匙串中，仅在匹配主机名/头部时注入）被视为一个突出特性。
  • 关于这是否足够抵御巧妙的数据外泄尝试存在争论；一些人担心会有方法把密钥反射回代理。
  • 出站防火墙/默认拒绝的网络策略很受重视；一些替代方案也实现了类似控制。

Linux 支持与平台缺口

  • 对 Linux 支持存在困惑和不满：营销页面最初未提及，文档和发布产物则显示支持 Ubuntu 和部分基于 RPM 的发行版。
  • 一些人抱怨它并未在所有 Linux 发行版或架构上广泛可用。

自建与开源替代方案

  • 很多用户都自建了自己的沙箱（QEMU/KVM、类似 Firecracker 的 microVM、Incus、devcontainers、bubblewrap、Apple Container、Tart、podman+libkrun 等）。
  • 许多人链接到提供基于 microVM 的代理、凭据代理、出站防火墙或更好 DX 的 OSS 项目。
  • 有几位表示，相比一个专有、需要登录门槛的工具，他们更愿意投资于开放、可自控的方案。