Cloudflare 宣布提供针对每个 Worker 的访问控制，使用户、软件代理或 API 令牌能够操作指定应用，而无法访问账户中的其他资源。此次更新还带来了开发者平台的四种新角色，旨在将应用监控、内容读取、修改和完整管理彼此分离。
这些控制措施自 2026 年 9 月 15 日起向所有客户开放，可通过 Cloudflare 控制面板、API 或 Terraform 进行配置。它们还可以应用于单个用户或 User Group，使组内所有成员继承相同的策略。
四个权限级别
- Metadata Read-Only：允许查看资源列表、资源设置和监控数据，例如指标、日志和追踪信息，但不能访问产品内容或代码。适用于无需读取源代码的故障调查。
- Content Read-Only：允许读取产品内容，例如 Worker 代码或 D1 数据库内容，但不能修改或部署更改。
- Editor：允许读取和写入内容以及更新设置，但不允许创建或删除资源。Cloudflare 将其作为 CI/CD 系统的合适选项，因为这类系统需要向指定 Worker 部署更改。
- Admin：授予对资源的完整控制权，包括创建、重命名、删除以及向其他用户授予访问权限，同时可以将该权限限制在单个 Worker，而不是整个账户。
实际会发生什么变化？
运营团队可以授予工程师或代理 Metadata Read-Only 权限，以便在不暴露代码的情况下检查设置、指标、日志和追踪信息。同样，代码审查代理可以使用 Content Read-Only 审查代码，但无法部署代码或更改应用设置。
对于 CI/CD 流程，可以创建一个具有 Editor 角色且仅限于单个 Worker 的 API 令牌。如果流程配置不当或令牌泄露，其能力仍将局限于为该应用部署更改，无法删除 Worker 或修改账户中的其他应用。Cloudflare 说明，这些权限适用于三个范围：完整的开发者平台、某个特定产品（例如 Workers），或某个特定资源（例如单个 Worker）。
关于范围和连接的重要限制
仅拥有 Worker 访问权限，并不足以添加、更改或删除 Route 或 Custom Domain。这些操作除了要求对 Worker 具有 Editor 权限外，还需要相应区域的 Workers Routes 权限。这种分离使用户能够管理流量如何路由到应用，而无需授予对域名设置更广泛的权限。
配置路由后，只要部署不改变现有连接，CI/CD 系统就可以继续部署新版本，同时不会获得对相关域名、数据库或存储的访问权限。Durable Objects 同样依赖于执行它们的 Worker 的权限；Metadata Read-Only 角色可以访问其指标、日志和追踪信息，但无法读取其中存储的数据。访问能够查询和修改数据的 Data Studio，则需要 Editor 角色。
错误消息和旧版本
Cloudflare 已更新操作被拒绝时的 API 响应，不再仅返回通用的 403 Forbidden 错误，而是加入指向相关文档的链接，说明所需的权限。预计这将帮助用户和代理更精确地配置权限，而不是随意扩大权限范围。
该公司建议迁移到新角色，而不是继续使用旧的 Workers 专属权限，但尚未公布停用时间；在发出提前通知之前，现有分配将继续有效。Cloudflare 计划将同一模型扩展到其他产品，包括 D1、R2 和 KV，使用户能够将访问权限限制在特定数据库或存储空间。
certi.news 解读
这里的实际变化并不只是增加了一个新的管理角色，而是将控制范围从账户或产品级别下沉到资源级别，并明确区分监控数据、内容和执行权限。这对于使用软件代理或自动化部署流水线的团队尤其重要，因为错误或令牌泄露可以被限制在单个 Worker 内。另一方面，路由和域名管理仍需要独立权限，而对 D1、R2 和 KV 的支持目前仍被列为后续计划，而非当前可用功能。至于旧权限在尚未公布退役时间的情况下继续存在，这意味着各机构需要逐步审查自身策略，而不能假定会立即完成迁移。