Claw Patrol: 一个面向代理的开源安全防火墙

# Claw Patrol：一个开源的代理安全防火墙 | Deno 来源：https://deno.com/blog/clawpatrol 在 Deno，我们运行着 Deno Deploy、JSR 以及其他多个生产服务。我们越来越多地使用代理来协助运维工作：处理 PagerDuty 告警、检查仪表盘、查询日志、执行 kubectl、回滚有问题的部署等等。 这意味着需要让代理访问工程师常用的许多生产系统：AWS、GCP、Postgres、Kubernetes、ClickHouse、GitHub、Slack、Grafana。 这需要极度谨慎，并带来一个两难问题。 权限有限的代理用处不大。但权限越大，危险性也越高：`kubectl delete namespace prod` 和 `psql -c 'DROP TABLE users'` 都只是一次工具调用就能完成的事情。 **不能指望代理进行自我约束**。代理进程持有工具（`psql`、`kubectl`、`gh`、`curl`）以及这些工具所需的凭证。一次提示注入、一次幻觉或一次错误的工具调用都可能滥用它们。 而且我们无法改变代理的行为方式。我们运行的绝大多数工具（Claude Code、Codex）都是我们安装的代码，而非我们编写的代码。任何解决方案都必须位于代理外部。 我们环境中的一个具体示例：我们有一个位于 VPC 内的生产 Aurora 数据库，只能通过 EKS API 服务器访问。如果我们的代理（7x24 小时运行）对此数据库拥有读取权限，将非常有帮助。但我们必须确保代理永远不会调用 `DROP TABLE`。 **这就是一个代理主机无法直接到达的出站网络路径，使用非 HTTP 的协议，受一条必须理解 SQL 的规则所限制。** 围绕这一领域，有越来越多的项目和产品： - **LLM 网关**（Helicone (https://helicone.ai/)、Portkey (https://portkey.ai/)、OpenRouter (https://openrouter.ai/)、LiteLLM (https://github.com/BerriAI/litellm)）和**内容护栏**（NeMo Guardrails (https://github.com/NVIDIA/NeMo-Guardrails)、Lakera (https://www.lakera.ai/lakera-guard)）监控模型调用。但代理与模型之外的其他服务进行通信；那些调用永远不会到达 LLM 网关。 - **HTTP 工具代理**（httpjail (https://github.com/coder/httpjail)、Crab Trap (https://github.com/brexhq/CrabTrap)）控制出站 HTTP 调用。但代理还使用 Postgres 和 SSH 等其他非 HTTP 协议。 - **进程沙箱**（NVIDIA OpenShell (https://github.com/NVIDIA/OpenShell)、agentsh (https://www.agentsh.org/)）通常专注于代理可进行的本地访问。我们已经将代理运行在独立的虚拟机中；对我们来说，这些方案作用有限。 - **凭证注入正向代理**（Agent Vault (https://github.com/Infisical/agent-vault)、Clawvisor (https://github.com/clawvisor/clawvisor)）终止 TLS、注入凭证并过滤出站 HTTP。它们根据 HTTP 方法和 URL 进行匹配，而非其他协议；它们决定允许或拒绝，而不会组合 LLM 裁判和人工审批链；并且它们不会继续隧道到代理主机无法到达的网络。（Deno Sandbox 提供了类似功能 (https://docs.deno.com/sandbox/security/)）。 **以上每种方案都只解决了部分问题**。然而，它们都无法处理除 HTTP 之外的协议，也没有任何一种组合能够通过 EKS API 服务器访问 Postgres 数据库，或者根据 SQL 动词进行限制。 对于接触真实生产系统的代理来说，这个缺口就是关键所在。 **今天，我们开源了我们针对此问题的解决方案：Claw Patrol** 代理流量通过 WireGuard 或 Tailscale 隧道传输到一个网关，该网关终止 TLS、解析内部协议、持有并注入真实凭证，并根据你用 HCL 编写的规则评估每个请求。该网关可以继续隧道到代理主机无法到达的网络（kubectl 端口转发到 EKS、Cloud SQL 代理、tailnet）。 以下是我们配置中的一条规则示例，用于拒绝跨部署集群读取 Kubernetes 密钥： ``` rule "k8s-no-secrets" { endpoints = [kubernetes.deploy-dev, kubernetes.deploy-prod] condition = "k8s.resource == 'secrets'" verdict = "deny" reason = "密钥值不得通过代理离开集群" } ``` 规则匹配解析后的协议要素：HTTP 方法、路径和正文；SQL 动词、表和函数；Kubernetes 动词、资源和命名空间。判定可以是 `allow`、`deny`，或是一个审批人链：一个根据你编写的策略进行判断的模型，一个 Slack 中的人工审批者，或者两者顺序执行。我们使用此链来限制代理起草的客户支持回复。LLM 检查正文中的 Markdown 格式和语气，然后 `#support` 频道中的人工审批者批准或编辑草稿。 **凭证存放在网关上，而非代理中**。代理发送一个像 `\{\{github_pat\}\}` 这样的占位符，网关在传输过程中替换为真实令牌。一个被攻破的代理进程无法泄露它从未持有的密钥。 --- 虽然我们很高兴分享 Claw Patrol（采用 MIT 许可证），但它目前是 alpha 软件。这是我们目前能正常工作的方案，因此协议支持的广度与我们所需的范围一致。你可以找到足够的文档来为其他协议编写支持代码。我们特别希望看到来自实际部署的规则模式、你希望下一步支持的协议，以及安装过程中的不足之处。欢迎提交 Issue 和 PR。 入门指南 (https://clawpatrol.dev/docs/getting-started/) 可以在五分钟内让你从零开始运行一个工作网关。 - 网站：clawpatrol.dev (https://clawpatrol.dev/) - 代码：github.com/denoland/clawpatrol (https://github.com/denoland/clawpatrol) - 安全模型 (https://clawpatrol.dev/docs/security-model/) - 架构 (https://clawpatrol.dev/docs/architecture/) - 演示 Claw Patrol 实例 (https://demo.clawpatrol.dev/)