Cloudflare Workers 推出细粒度访问控制：为每位成员与 Agent 分配恰当权限
译注：本文翻译自 Cloudflare 官方博客，原文发布于 2026 年 9 月 15 日，作者为 Dina Kozlov、Anthony Oreglia 与 Visal。原文链接见文末。
随着越来越多团队——以及如今的 AI Agent——在 Cloudflare 开发者平台上构建应用，拥有恰当的访问控制对于安全交付至关重要。毕竟，你最不希望看到的情况，就是某个 Agent 仅仅因为被授予了超出所需的权限，而在生产环境中做出改动。现在，你可以让某位团队成员或 Agent 只访问某个特定的 Worker，使其仅能修改该应用，而无法触碰账户中的其他资源。
此外，Cloudflare 还新增了四种角色，以便精确限制他们能做什么：
| 角色 | 允许的操作 | 适用场景 |
|---|---|---|
| Metadata Read-Only（元数据只读） | 查看资源列表、设置以及可观测性数据（如指标、日志和追踪），但无法访问产品内容 | 希望让成员或 Agent 访问可观测性数据以便排查问题，但不希望其接触源代码 |
| Content Read-Only（内容只读） | 读取产品内容，如 Worker 代码或 D1 数据库内容，但无法修改 | 希望让成员或 Agent 访问源代码，但不希望其改动 Worker |
| Editor（编辑者） | 读写产品内容并更新设置，但不能创建或删除资源 | 希望让成员、Agent 或 CI/CD 系统部署 Worker 变更，但阻止其删除 Worker |
| Admin（管理员） | 对资源拥有完全控制权，包括创建、重命名、删除以及向其他用户授予访问权限 | 希望让成员或 Agent 完全掌控某个 Worker（包括删除），但不授予账户中其他 Worker 或资源的访问权限 |
这些新角色即日起面向所有客户开放。你可以将其分配给特定用户，该用户登录控制台后只会看到被授权的 Worker；也可以创建带有相应作用域的 API Token，交给 Agent 使用，确保它只能访问那一个应用。
以下是一个按 Worker 粒度创建 API Token 的示例。
为团队协作方式而设计的角色
在定义这些角色时，Cloudflare 希望取得平衡：过于宽泛的角色会迫使你授予超出预期的权限，违背最小权限原则；而提供过多细碎的权限又让人难以判断该授予哪些。最终确定的四种角色，对应你可能想给予某人或某个 Agent 的访问层级：足以调试资源而不暴露其内容、读取内容而不修改、做出变更而无法删除资源，或完全管理资源。Cloudflare 计划在将资源级访问控制扩展到 D1、R2 和 KV 等其他开发者平台产品时，沿用同一套角色。
每个角色都可以应用在三种作用域之一。以“元数据只读”为例，不同层级的效果如下：
- 开发者平台层级：访问所有开发者平台资源的元数据。
- 产品层级：访问某一产品（例如所有 Worker）的元数据。
- 资源层级：访问某一特定资源（例如某一个 Worker）的元数据。
角色与作用域共同决定了某人能做什么，以及能对哪些资源做。
常见 Workers 工作流示例
在不暴露源代码的前提下调试。 为排查问题，工程师或 Agent 可能需要查看 Worker 的设置、指标、日志和追踪，以理解出错原因，但无需查看代码或做出改动。Metadata Read-Only 让他们获得这些信息而不暴露源代码。他们可以通过 GraphQL API 查询分析数据、访问日志、检查追踪等可观测性数据，而这些请求只会返回其有权访问的 Worker 的数据。如果某个 Agent 被限定在单个 Worker 上，它就能使用 Cloudflare API 调查问题，而看不到账户中其他 Worker 的数据。随着这些角色扩展到更多开发者平台产品，这种隔离也将保留：某人可以检查 D1 数据库或 R2 存储桶的设置与可观测性数据，而无法读取数据库中的值或存储桶中的文件。
审阅代码而不做改动。 团队成员或代码审查 Agent 可能需要读取 Worker 中运行的代码，以理解其工作方式、调查缺陷或审阅拟议的变更，但这并不意味着他们应该能够部署新代码或更新 Worker 设置。Content Read-Only 提供了这种隔离，允许其获取并审阅 Worker 代码，但无法修改或部署。当作用域限定为单个 Worker 时，他们只能读取该 Worker 的代码，而非账户中所有 Worker 的代码。待其他开发者平台产品支持后，Content Read-Only 的行为一致：可以读取 D1 数据库、KV 命名空间或 R2 存储桶中的数据，但无法修改。
让 CI 部署而不赋予完全控制权。 CI/CD 工作流只需要访问它所部署的应用，不应能改动其他 Worker，也不应能删除自身导致应用下线。借助 Worker 级访问控制，每个工作流都可以拥有自己的 API Token，使用 Editor 角色并限定到单个 Worker。即使工作流配置错误或 Token 泄露，影响也被限制在可控范围内：它可以向该 Worker 部署变更，但无法删除它，也无法触碰账户中的其他应用。
以 Admin 权限删除 Worker。 Admin 是最高级别的访问权限，允许删除应用。你仍可将该角色限定到单个 Worker，使权限不会扩展到账户中的所有 Worker。
路由与自定义域名
你可以为 Worker 添加路由或自定义域名，指定哪些主机名路由到该应用。例如，Wrangler 文件中的以下配置会将 example.com 的流量发送到该 Worker：
{
"route": {
"pattern": "example.com/*",
"zone_name": "example.com"
}
}由于更改该路由可能重定向生产流量或导致应用下线，仅拥有 Worker 访问权限是不够的。要添加、更改或移除路由或自定义域名，你既需要对该 Worker 的 Editor 访问权限，也需要该 zone 的 Workers Routes 权限。要求 Workers Routes 权限而非更宽泛的 zone 访问权限，意味着某人可以管理流量如何到达 Worker，却无法更改该域名的无关设置。不过，一旦路由配置完成，只要部署不改变该连接，你就可以在没有所连接 zone 或资源访问权限的情况下继续部署 Worker 的新版本。这让 CI/CD 系统能够部署应用，而无需同时获得你的域名、数据库或存储的访问权限。
Workers 权限延伸至 Durable Objects
Durable Objects 没有自己的角色或权限，其访问权限取决于你对实现它的 Worker 的访问权限。要授予某人访问某个 Durable Object 的权限，需为其授予该 Worker 的相应角色。Metadata Read-Only 让他们可以访问 Durable Object 的指标、日志和追踪，但无法访问对象中存储的数据。由于 Durable Objects Data Studio 可以直接查询和修改存储的数据，访问它需要 Editor 角色。
更清晰的错误提示
当你授予较窄的权限时，对方最终可能会尝试执行无权进行的操作。此时，错误信息应告知其需要什么权限，以免卡住。Cloudflare 的 API 不再只返回笼统的 403 Forbidden，而是附带相关 API 文档链接，你可以在其中看到发起该请求所需的确切权限。这样，你和你的 Agent 就能准确判断所需的访问级别，而无需授予不必要的更宽权限。
现已可用
Worker 级访问控制即日起面向所有客户开放，可通过 Cloudflare 控制台、API 或 Terraform 配置。要为某位团队成员授予特定 Worker 的访问权限，请前往 Manage Account > Members，选择该成员，并创建带有其所需角色和 Worker 作用域的策略。
使用用户组管理团队访问。 如果同一团队或项目中的多个人需要相同权限，可以创建 User Group，而不必逐一分配。将策略分配给该组，然后添加相关成员，组内所有人将自动继承该策略。
替换 Workers 的旧版权限
此前，Cloudflare 使用以下角色和权限管理 Workers 的访问。随着在开发者平台推行一致的权限角色，建议今后使用新角色。
| 旧角色 | 成员/API Token | 推荐的新角色 |
|---|---|---|
| Workers Platform (Read-Only) | 成员 | Developer Platform Content Read-Only |
| Workers Platform Admin | 成员 | Developer Platform Admin |
| Workers Scripts Read | API Token | Content Read-Only |
| Workers Scripts Edit | API Token | Editor |
| Workers CI Read | API Token | Content Read-Only |
| Workers CI Edit | API Token | Editor |
| Workers Observability Read | API Token | Metadata Read-Only |
| Workers Observability Edit | API Token | Editor |
| Workers Observability Telemetry Edit | API Token | Editor |
| Workers Tail Read | API Token | Metadata Read-Only |
旧角色和权限没有弃用日期。现有分配将继续有效，任何弃用都会提前通知。不过，Cloudflare 建议开始迁移到新角色，因为只有新角色支持细粒度的资源级访问。
下一步
Worker 级访问是迈向 Cloudflare 开发者平台更一致授权模型的第一步。接下来，Cloudflare 将把同样的资源级访问控制带到更多开发者平台产品，包括 KV 命名空间和 D1 数据库等资源。届时，你无需再授予某人访问账户中每个存储桶或每个数据库的权限，而是可以将访问限定到其所需的特定资源，并搭配恰当的角色。为 Workers 引入的同一套角色也将适用。