为每位团队成员和 AI agent 授予合适的 Workers 访问权限

随着越来越多的团队——以及如今的 agent——在 Cloudflare 的 Developer Platform 上构建应用，拥有合适的访问控制对于安全发布至关重要。毕竟，你最不希望看到的就是 agent 仅仅因为被授予了超出所需的权限，就对生产环境做出更改。现在，你可以让某个队友或 agent 只访问某个特定的 Worker，这样他们就只能修改那个应用，而无法触碰你账户中的其他资源。此外，我们还新增了四个角色，让你能精确限制他们可以做什么：

角色	允许做什么	适用场景
Metadata Read-Only	查看资源列表、设置以及可观测性数据（如指标、日志和 trace），但无法访问产品内容。	当你想让某个团队成员或 agent 访问可观测性数据以便排查问题时，
但你不想让他们访问你的源代码。
Content Read-Only	读取产品内容，例如 Worker 代码或 D1 数据库内容，但无法修改。	当你想让某个团队成员或 agent 访问源代码时，
但你不想让他们对 Worker 做出任何更改。
Editor	读写产品内容，并更新设置。无法创建或删除资源。	当你想让某个团队成员、agent 或你的 CI/CD 系统能够将更改部署到你的 Worker 时，
但你希望防止他们删除该 Worker。
Admin	对资源拥有完全控制权，包括创建、重命名、删除以及向其他用户授予访问权限。	当你想让某个团队成员或 agent 对你的 Worker 拥有完全访问权限，包括删除它的能力时，
但你不想授予对账户中任何其他 Worker 或资源的访问权限。

新角色即日起面向所有客户开放。你可以将它们分配给特定用户，这样当他们登录 dashboard 时，只会看到你授予他们访问权限的那个 Worker。或者，你也可以创建一个带有相应权限范围的 API token，交给你的 agent，确保它只能访问那一个应用。

下面是一个按 Worker 分别授予权限的 API token 创建示例：

为团队协作方式设计的角色

定义这些角色时，我们想找到一个恰当的平衡点。角色范围太宽，你就不得不授予超出本意的访问权限，最小权限原则也就无从谈起；而拆成一大堆细碎的权限，又让人搞不清到底该给哪些。最终我们定下四种角色，对应你可能想授予某个人或某个 agent 的访问级别：足以调试某个资源但不暴露其内容、读取内容但不做修改、可以改动但不能删除资源，以及完全管理该资源。

我们计划把这套角色沿用到其他 Developer Platform 产品上，包括 D1、R2 和 KV，逐步引入资源级访问控制。每个角色都可以应用在三种范围之一。以“metadata read-only”为例，不同层级下的效果如下：

• Developer Platform 层级：可访问所有 Developer Platform 资源的元数据。
• 产品层级：可访问某一产品下所有资源的元数据，比如所有 Worker。
• 资源层级：可访问某一个具体资源的元数据，比如某一个 Worker。

角色和范围共同决定了一个人能做什么，以及能对哪些资源做。下面看看这在几种常见的 Workers 工作流中是什么样子。

调试而不暴露源代码

要排查问题，工程师或 agent 可能需要查看某个 Worker 的设置、指标、日志和 trace，弄清哪里出了错。但他们不需要看到 Worker 的代码，也不需要改动它。

Metadata Read-Only 让他们能拿到这些信息，同时不暴露 Worker 的源代码。他们可以通过 GraphQL API 查询分析数据、访问日志、检查 trace 和其他可观测性数据。这些请求只会返回他们有权访问的 Worker 的数据。如果某个 agent 的范围限定在一个 Worker 上，它就能借助 Cloudflare API 排查问题，而看不到该账户中其他任何 Worker 的数据。

随着我们将这类角色推广到更多 Developer Platform 产品，我们计划保留这种分离。用户可以查看 D1 数据库或 R2 存储桶的设置和可观测性数据，却无法读取数据库中的值或存储桶中的文件。

审查代码，但不改动代码

同事或代码审查 agent 可能需要读取 Worker 中运行的代码，以了解其工作方式、排查 bug 或审查一项改动提案。但这并不意味着他们应该能够部署新代码或更新 Worker 的设置。

Content Read-Only 提供了这种分离。它让用户可以获取并审查 Worker 的代码，却无法修改或部署它。当权限范围限定到单个 Worker 时，他们只能读取该 Worker 的代码，而不是账户中所有 Worker 的代码。

一旦其他 Developer Platform 产品也支持，Content Read-Only 的行为将完全一致：用户可以读取 D1 数据库、KV 命名空间或 R2 存储桶中存储的数据，却无法修改它。

让 CI 部署，但不给它完全控制权

CI/CD 工作流只需要访问它所部署的应用。它不应该能改动另一个 Worker，也不应该能删除自己部署的 Worker、让应用下线。

有了 Worker 级别的访问控制，每个工作流都可以拥有自己的 API token，带上 Editor role，并限定到某一个 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 没有自己的角色或权限。对某个 Durable Object 的访问权限，取决于你对实现它的那个 Worker 的访问权限。要授予某人访问某个 Durable Object 的权限，就给他对应的 Worker 角色。

Metadata Read-Only 让他可以访问 Durable Object 的指标、日志和 trace，但访问不到对象中存储的数据。由于 Durable Objects Data Studio 可以直接查询和修改这些存储的数据，访问它需要 Editor 角色。

更清晰的报错，告诉你和你的 agent 缺哪项权限

当你授予某人范围很窄的权限时，他迟早会尝试执行自己没有权限的操作。这时，报错应该说明他需要哪项权限，免得他卡在那里。

现在，API 不再只返回笼统的 403 Forbidden，而是会附带相关 API 文档的链接，你可以从中了解发起该请求具体需要哪些权限。这样，你和你的 agent 就能准确判断所需的访问级别，而不必授予超出必要的权限。

现已可用

Worker 级别的访问控制现已面向所有客户开放。你可以在 Cloudflare dashboard 中配置，也可以通过 API 或 Terraform 配置。

要让某个团队成员访问特定的 Worker，请前往 Manage Account > Members，选中该成员，然后创建一条策略，指定其所需的角色和 Worker 范围。

用用户组管理团队访问权限

如果同一团队或项目中多个人需要相同的访问权限，你可以创建一个用户组，而不必逐个分配权限。把策略分配给该用户组，然后加入相关成员。组内所有人都会自动继承这条策略。

取代 Workers 的旧版权限

此前，我们使用以下角色和权限来管理对 Workers 的访问。既然我们正在 Developer Platform 上推行一套统一的角色，今后建议使用新角色。

旧版角色	Member/API Token	推荐的新角色
Workers Platform (Read-Only)	Member	Developer Platform Content Read-Only
Workers Platform Admin	Member	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

旧版角色和权限没有弃用日期。现有分配继续有效，任何弃用之前我们都会提前通知。即便如此，我们仍建议你开始迁移到新角色，因为只有新角色支持细粒度的资源级访问控制。

接下来

Worker 级访问控制只是第一步，目标是让 Cloudflare 开发者平台上的授权模型更加一致。

接下来，我们会把同样的资源级访问控制带到更多开发者平台产品，包括 KV 命名空间、D1 数据库这类资源。你不再需要把账号下所有 bucket 或所有数据库的访问权限都授予某人，而是可以只限定在他真正需要的那个资源上，再配上合适的角色。

为 Workers 引入的这套角色同样适用于这些资源。

开始使用请查阅我们的开发者文档。