本页带你完成组织治理的设置,从规划你的第一批策略到确认它们在开发者机器上正常工作。每个 步骤都说明要做什么、要决定什么,并链接到包含完整说明的页面。
开始之前
你需要:
- 组织的 Docker AI Governance 方案。
- 把开发者添加为组织成员。要把策略 限定到某些开发者群体(例如试点团队),还要为他们 创建团队。
- 组织 owner 角色,或带有 Governance 权限的 自定义角色。
- 开发者机器的终端管理工具的访问权限,例如 MDM 解决方案或组策略,用于强制执行登录。
第 1 步:规划要允许的内容
组织策略采用默认拒绝。一旦对某位开发者强制执行组织策略,他们的沙箱就只能访问你的策略 所允许的网络目标,只能挂载你的策略所允许的宿主路径,也只能按你的策略许可的方式使用 MCP 服务器。更多细节请参阅组织策略。
在治理任何人之前,先弄清楚他们的沙箱需要什么:
- 网络目标,例如 AI 提供商的 API、软件包镜像仓库和代码托管服务。
- 沙箱作为工作区挂载的宿主路径。默认情况下,
sbx run会挂载运行时的当前目录,因此要 允许开发者存放项目的目录。如果工作区不在允许范围内,沙箱将无法启动。 - 开发者用
sbx mcp add添加的 MCP 服务器。智能体不经sbx直接连接的服务器属于网络 目标,因此应改用网络规则来规划。
在分配许可证之前,你可以在开发者的机器上运行 sbx policy log,查看其沙箱发起的网络 请求。开发者受治理之后,你的审计日志会更详细地记录他们的网络请求、挂载和 MCP 活动。 如果你不确定沙箱需要什么,可以先用你有把握的规则启动试点团队,然后查看审计日志,找出 被策略拒绝的请求,并在开发者需要的地方添加允许规则。配置审计交付并分配许可证之后, 审计记录才可用。
然后决定如何划分策略的作用范围。对于必须处处生效的护栏(例如即使团队作用域策略允许 也要阻止某个目标的拒绝规则),使用全组织范围的策略;对于只有部分团队需要的访问权限, 使用团队作用域的策略。要了解两者如何组合的示例,请参阅 规则如何判定请求。在推广到所有人之前, 先从一个试点团队开始。
第 2 步:创建策略
在 Docker Home 中展开 AI Platform,在 Network access、 Filesystem access 和 MCP access 下创建策略。在分配任何许可证之前,至少创建一个 网络策略和一个文件系统策略,这样受治理的开发者才能继续工作。把第一批策略限定到试点团队。
有关具体步骤,请参阅创建和管理组织策略。
第 3 步:配置审计交付
审计日志记录你的开发者沙箱所做出的策略决策。在分配许可证之前配置交付,这样从第一个 受治理的请求开始就能收集记录。在 Docker Home 中进入 AI Platform > Audit logs, 选择记录的交付位置。更多细节请参阅配置审计交付。
第 4 步:开启 AI 治理
只有为你的组织开启 AI 治理后,你的策略才会生效。在 Docker Home 中展开 AI Platform, 选择 Manage,然后开启 AI governance。如果你还没有创建文件系统策略,Docker Home 会先给出警告,因为没有它,受治理的开发者无法使用 Docker Sandboxes。
开启 AI Governance 暂时不会治理任何人。组织策略仅适用于持有 AI Governance 许可证的成员, 你可以在第 5 步中分配许可证。
开启之后,也可以考虑在同一个页面上 配置支持消息。当你的策略阻止请求时, 开发者会看到该消息,你可以借此告知他们如何申请访问权限。
第 5 步:分配许可证
组织策略仅适用于持有 AI Governance 许可证的成员。先向试点团队的成员分配许可证。更多细节 请参阅管理许可证。
如果为 AI Governance 开启了自动分配许可证,每一位登录 Docker Sandboxes 的成员都会获得 许可证,并从首次登录起受治理。试点期间请保持关闭。
第 6 步:强制执行登录
如果没有登录强制要求,开发者可以用个人账户登录 Docker Sandboxes,从而避开你的策略。 使用你的终端管理工具,把一份列出开发者必须所属组织的强制执行配置部署到开发者的机器上。 更多细节请参阅强制执行登录。
第 7 步:部署 Docker Sandboxes
如果你的开发者还没有 Docker Sandboxes,请在分配许可证并强制执行登录之后再部署,这样 开发者从首次登录起就受治理。有关安装方式,请参阅 安装 Docker Sandboxes。
第 8 步:在开发者机器上验证
在试点团队某位开发者的机器上,你可以立即获取最新的组织策略,而不必等待下一次同步:
$ sbx policy refresh确认组织策略已强制执行。状态行应显示你的组织:
$ sbx policy ls检查一个你的策略允许的目标地址和一个不允许的目标地址:
$ sbx policy check network api.anthropic.com
$ sbx policy check network blocked.example.com第一次检查应报告 Allowed,第二次应报告 Denied。然后运行一个沙箱,并用 sbx policy log 查看它发起了哪些请求、匹配了哪些规则。更多细节请参阅 检查策略状态和规则以及测试和监控网络策略。
第 9 步:推广到更多团队
当试点团队按预期工作后,向更多成员分配许可证,把 Docker Sandboxes 部署到他们的机器上, 并扩大策略的作用范围,或为需要不同访问权限的团队添加团队作用域的策略。随着更多开发者 受治理,请持续查看审计日志,找出被策略阻止的请求,并在开发者需要的地方添加允许规则。 你所做的每项更改都会在 5 分钟内到达开发者机器。更多细节请参阅 策略更改何时到达开发者。