Cloudflare Worker 权限细化：把客户部署锁定到单个 Worker

Cloudflare 的 4 种 Worker 角色，把一套共享部署凭证变成了按客户划分的 Cloudflare Worker 权限边界。自 2026 年 9 月 15 日起，只要没有更宽泛的策略叠加放大权限，代理商就能允许客户的 CI 任务只部署某个现有 Worker，同时不给它删除权限，也不让它访问账户里的其他所有 Worker。

Cloudflare Worker 权限真正改变的是作用域

一项权限由两部分构成：角色决定可以做什么，作用域限定可以在哪里做。

Cloudflare 现在允许将 Worker 角色与单个 Worker 作用域组合，再授予团队成员、User Group、Agent 或 API Token。同一个角色仍可覆盖全部 Worker，但已不必如此。

这看起来只是个小型管理功能。可对在同一 Cloudflare 账户中承载多个客户项目的工作室或代理商来说，交接方式由此改变：Client A 的部署凭证可以只触达 Client A 的 Worker。

9 月 15 日发布的更新 面向所有客户开放，可通过控制面板、API 或 Terraform 使用。

以下是 Workers 角色参考文档 中的完整角色列表：

这种拆分很实用，因为调试、代码审查、发布代码和删除服务本来就是 4 类不同的工作，不该默认共用同一套凭证。

Cloudflare 旧版 Workers 权限以账户为作用域。替代它的新模型既可覆盖整个 Developer Platform，也可覆盖全部 Workers，或只限定到某个现有 Worker。产品级 Workers 策略覆盖当前及未来的每个 Worker；单 Worker 策略则只覆盖明确选中的 Worker。

这里有一个结构性限制：尚未存在的 Worker 无法成为作用域。创建新 Worker 仍然需要产品级 Admin。

交接给客户时，具体变了什么

以一家小型代理商为例，它为每位客户托管一个 Worker。其部署流程只需发布 client-a-api 的新版本，无需创建 Worker、删除这个 Worker，也不该触碰 client-b-checkout。

在此次更新之前，Cloudflare 现已标为 legacy 的常见 Workers CI 权限均为账户级。此前只有两个清晰选项：接受一套权限宽泛的凭证，或把客户拆到另一个账户。单 Worker 作用域带来了第三条路：保留原有账户结构，但只给部署 Token 对 client-a-api 的 Editor 权限。

由于 Worker 级权限控制向所有客户开放，订阅成本没有变化，运维成本的计算方式却变了。

这个模型没有计入一项重要代价：与一套共享 Token 相比，12 套按客户限定的凭证意味着要签发、存储和轮换更多密钥。收益并不是凭证变少，而是在某套凭证失效或泄露时，需要排查的项目范围更小。

如果独立开发者只有一个 Worker，也不共享部署权限，变化并不明显。有意让平台团队管理全部 Worker 的组织也是如此。真正受益的是那些让多位成员、客户或自动化任务共用一个 Cloudflare 账户，却不希望它们共享同一故障影响范围的团队。

给单个客户部署任务配置刚刚好的权限

最适合先交接的，是已经存在、且 Route 或 Custom Domain 稳定不变的 Worker。这样，部署任务无需负责创建 Worker，也不需要修改域名连接。

1. 1

   先写清任务，再选择角色

   先用一句话定义任务：“这个流程负责部署现有 client-a-api Worker 的新版本。”

   这句话对应的是单个 Worker 作用域下的 Editor。如果任务必须创建新 Worker，就需要产品级 Admin；如果必须添加、更改或移除 Route 或 Custom Domain，还需要对每个受影响的 zone 拥有 Workers Routes Write。

2. 2

   创建账户拥有的 API Token

   在 Cloudflare 中进入 Manage Account > Account API Tokens，创建一个由账户拥有的 Token。将作用域设为 Specified Workers，选择 client-a-api，再选择 Editor。

   工作流应使用账户拥有的 Token，而不是某个人的用户 Token。Cloudflare 将账户拥有的 Token 定位为持久集成所用的服务主体，因此即使创建者离职，部署也不会随之中断。创建或更新这类 Token 需要 Super Administrator 权限。

3. 3

   使用该 Token 运行 Wrangler

   把 Token 存入部署系统的密钥存储。Cloudflare 为 Wrangler 提供了以下环境变量：

   export CLOUDFLARE_API_TOKEN="<YOUR_API_TOKEN>"
   export CLOUDFLARE_ACCOUNT_ID="<YOUR_ACCOUNT_ID>"
   npx wrangler deploy

   请在已配置好现有 Worker 的项目中运行这些命令。这里不能用 wrangler login 替代，因为它的 OAuth 流程目前不支持细粒度授权。

4. 4

   完成切换，再移除宽权限通道

   先用新 Token 部署一个无影响的版本，并确认更新发生在目标 Worker 上。检查该 Token 没有产品级 Workers 角色，也没有无关的资源作用域。

   随后，从这个工作流中移除旧的宽权限部署密钥。测试期间同时保留两套凭证很合理；测试结束后继续保留，则会让这道权限边界失去意义。

常规部署的完整交接到这里就结束了。由于更新、上传、部署、回滚、重命名以及管理该 Worker 的密钥都属于 Editor 权限，客户任务可以完成这些操作；但它无法删除 Worker，单 Worker 策略也不会授予它访问其他 Worker 的权限。

4 类任务，4 套合理策略

只需收集证据的支持 Agent

给调试 Agent 授予目标 Worker 的 Metadata Read-Only。它可以检查设置、指标、日志和追踪，却无法读取源代码或更改服务。

这样，支持流程可以收集证据，而不会悄然变成代码审查或部署流程。同一角色也足以在该 Worker 上运行 wrangler tail。

审查客户项目的外部开发者

给承包方授予客户 Worker 的 Content Read-Only。他们可以查看已部署的源代码和设置，但不能修改或部署它。

这样能形成更清晰的审查边界。审查者只是需要了解当前运行的内容，并不意味着必须获得 Editor。

客户专用的 CI 流水线

让账户拥有的 Token 只对一个现有 Worker 拥有 Editor。它可以发布和回滚版本，却不能删除该 Worker，也无法触达其他 Worker。

这是最适合代理商交接的方案，因为凭证属于工作流，而不是某位员工。如果还会为客户运行浏览器 Agent，Cloudflare 的获准主机控制解决的是边界的另一半：浏览器可以访问哪里。此次更新控制的则是部署身份可以更改哪个 Worker。

负责生命周期变更的平台负责人

Admin 应只留给确实需要删除权限的成员或自动化任务。创建 Worker 的负责人继续持有产品级 Admin，再把已完成的 Worker 交给权限更窄的日常策略。

这样，生命周期管理与日常交付之间便有了清晰分工。部署任务不需要拥有与创建和停用客户服务的负责人同等的权限。

权限边界更窄，但并非完全隔离

核心收益确实存在，但把它简单理解为“只能访问一个 Worker”可能很危险。

Durable Objects 也需要同样谨慎。它们没有独立的角色或作用域，而是继承实现它们的 Worker 的访问权限。Metadata Read-Only 包含 Durable Object 的指标、日志和追踪，但不包含存储数据访问；不过，按文档列出的门槛，Editor 也足以使用 Data Studio 查询或修改基于 SQLite 的 Durable Object 中的数据。

Routes 是另一道独立边界。如果现有 Route 或 Custom Domain 保持不变，Editor 足以部署新版本；若要更改这种连接，还必须对每个受影响的 zone 拥有 Workers Routes Write。Cloudflare 还说明，Custom Domains 目前不支持单 Worker 角色。

最后，Cloudflare 的权限会叠加。直接授予的窄权限策略，不会抵消通过 User Group 继承的宽权限策略。Members 视图显示直接权限，继承的群组策略则必须到 Groups 标签页检查。跳过这一步，界面上或许显示的是预期的窄权限策略，实际生效的权限范围却仍然很宽。

哪些团队现在就该行动

如果一个账户承载多个客户 Worker，而某位成员、Agent 或 CI 任务为了只操作一个 Worker，仍然持有覆盖全部 Workers 的权限，就应在本周采取行动。目标 Worker 已经存在，且日常部署不会更改其域名连接时，收益最明显。

如果工作流需要创建 Worker、更改 Route 或 Custom Domain，或依赖直接访问绑定的数据产品，先不要急着收紧 Token。应先梳理这些操作，否则下一次部署可能进行到一半就失败。

如果从不共享 Worker 访问权限、只运行一个 Worker，或有意让承担账户级职责的平台团队统一掌管部署，则基本不受此次变化影响。

周一先做这一件事

先改造一个现有客户 CI 部署背后的权限策略：将一个账户拥有的 Token 设为 Editor，把作用域限定到该 Worker，列出它可以影响的每项绑定及继承的 Durable Object，检查直接策略和群组策略，然后在不更改 Route 或 Custom Domain 的情况下完成部署。

确认这次部署通过后，移除旧的全 Workers 密钥。完成这一次切换，就有了一道真正的边界，也得到了一套可复用于下一个客户的做法。

如果希望继续阅读用直白语言解读平台变化的实操内容，欢迎订阅邮件通讯。