Cloudflare 推出 Workers 资源级权限：代理运维审计指南
Cloudflare 于 2026 年 9 月 15 日宣布为 Workers 提供资源级访问控制。此次更新新增 Metadata Read-Only、Content Read-Only、Editor 和 Admin 四类角色，并可在 Developer Platform、具体产品或单个 Worker 层级应用。所有客户均可通过控制台、API 与 Terraform 使用这些角色。
这项变化与代理运维直接相关：边缘代码常参与请求规范化、路由、可观测与凭据处理。只看指标的人不应同时获得源码权限；部署流水线也不应能删除其他 Worker。新模型能清晰表达这些边界，但团队仍需把角色映射到真实任务，并验证“应该被拒绝”的路径。
四类角色如何分工
| 角色 | 主要能力 | 代理运维场景 |
|---|---|---|
| Metadata Read-Only | 查看列表、设置与可观测数据，但不读取源码内容 | 值班人员检查延迟、错误、日志与追踪 |
| Content Read-Only | 读取内容或代码，但不能修改 | 审阅请求规范化 Worker 的审核人员 |
| Editor | 读取并更新内容与设置，但不能创建或删除资源 | 只向一个 Worker 部署已批准版本的 CI |
| Admin | 包括创建、重命名、删除与授权在内的完整控制 | 受限的紧急管理账号 |
这些角色可以缩小到单个 Worker。Cloudflare 的示例显示，CI/CD 可仅获得某个 Worker 的 Editor 权限，从而能部署，但不能删除该 Worker，也不能修改其他 Worker。
先盘点所有访问主体
列出能访问边缘平台的人员、服务账号、智能代理、CI 任务与 API 令牌。为每个主体记录负责人、业务目的、目标 Worker、允许动作、到期或复核日期，以及撤权方法。
不要因身份名称不清晰就授予宽泛角色。应先重命名或替换含义模糊的凭据。部署、监控和紧急管理共用一个令牌，会破坏审计归因，也会让撤权造成更大影响。
部署工具需要构造代理认证值时，可参考代理凭据编码验证指南。仓库侧的防泄漏措施可结合GitHub 代理密钥阻断更新。
按动作选择最窄角色
从实际动作出发，而不是从职位名称出发：
- 只需指标与追踪的值班观察者，优先给予目标 Worker 的 Metadata Read-Only。
- 只有必须检查源码时，才给代码审阅者 Content Read-Only。
- 部署任务仅获得其负责 Worker 的 Editor。
- Admin 只保留给极少数、受监控的紧急路径。
- 临时事件权限必须设置时限，并实际验证到期后已失效。
不要为了“以后可能有用”叠加角色。一个工作流确实需要两项权限时，应记录原因并分别测试。
将代码部署与路由变更分开
Cloudflare 指出，自定义域名和路由变更同时需要 Worker 的 Editor 权限，以及相关区域的 Workers Routes 权限。这种拆分很重要：修改代码和决定流量去向是两个不同的风险决策。
日常部署身份不应修改生产路由。路由或自定义域名变更应使用独立审批，并把区域权限限制在最小范围。变更后既要确认 Worker 版本，也要验证公开路由。代码上传成功并不表示流量已经进入预期版本。
可参考代理市场故障转移验收测试，通过小流量验证避免把单一区域问题放大为全球切换。
把密钥当作独立控制面
资源级权限能减少不必要的访问，但不能让已泄露的密钥变安全。代理用户名、密码、令牌与端点凭据应保存在批准的密钥机制中，禁止写入 Worker 源码、构建产物、命令历史、分析维度或日志。
可观测记录不应包含完整 Authorization 头、Cookie、代理 URL 或稳定会话标识。导出前应散列或脱敏，并按运维需要设置留存期限。
验证拒绝路径
权限策略不能只靠一次成功部署来证明。应在非生产环境确认：
- Metadata Read-Only 能看允许的遥测，但不能取得源码；
- Content Read-Only 能审阅代码，但不能发布版本；
- Editor 能更新指定 Worker，但不能删除它；
- 只作用于 Worker A 的身份无法查看或修改 Worker B；
- 没有 Workers Routes 权限的部署身份无法改变路由；
- 已撤销或过期的权限及时失败，并产生可归因审计事件。
Cloudflare 表示，API 授权错误现在会给出相关权限文档提示，而不是只有通用 403。它适合用于诊断，不应触发自动提权。缺失权限也可能说明工作流正在执行不该执行的动作。
通过小范围验证迁移旧权限
Cloudflare 尚未弃用旧权限，但建议迁移到新角色。不要一次替换所有身份。先选一个低风险 Worker，建立窄范围身份，执行读取、部署与拒绝测试，再观察一个完整运维周期。
记录新旧策略、负责人、回退条件与移除日期。新角色证明足够后，应撤销旧授权，避免两套权限长期并存。可先从只读监控开始，再逐步覆盖部署和管理。
审计检查清单
- 每个人员、代理、CI 任务与令牌都有明确负责人。
- 每个主体都限制到最小 Worker 或产品范围。
- 监控、代码审阅、部署与管理使用独立身份。
- 普通 CI 尽量使用 Editor，而不是 Admin。
- 路由变更需要独立区域权限与审批。
- 代理凭据不进入源码、构建产物或日志。
- 成功与拒绝测试都有记录。
- 临时权限的到期与撤权路径经过验证。
- 小范围迁移成功后移除旧授权。
- 授权错误触发复核，而不是自动扩权。
常见问题
Editor 能让 CI 删除 Worker 吗？
不能。Cloudflare 将 Editor 定义为可更新内容与设置，但不能创建或删除资源。仍应在非生产环境验证实际行为。
Metadata Read-Only 是否足够用于事件响应？
对于只需设置、指标、日志和追踪的观察者，它是合适的默认角色。只有任务确实需要查看或修改代码时才升级。
Worker 权限是否自动包含路由变更？
不包含。Cloudflare 指出，路由和自定义域名还需要对应区域的 Workers Routes 权限。
自动化是否应根据 403 提示申请更高权限？
不应。先比较尝试动作与已批准工作流，再由负责人判断是动作错误还是策略需要调整。
合规说明
仅对组织拥有或获授权管理的账户与边缘资源实施访问控制。遵守内部审批、审计、留存与区域数据要求。不得利用代理基础设施或受限身份绕过服务控制、隐藏未授权访问或未经许可收集数据。
