Give every teammate and agent the right level of access to your Workers

为每个团队成员和代理提供适当的Workers访问权限 | Cloudflare Blog

post

安全

Workers

开发者

身份验证

产品新闻

2026年9月15日

为每个团队成员和代理提供适当的Workers访问权限

Dina Kozlov , Anthony Oreglia , 和 Visal In

8分钟阅读

复制链接

随着越来越多的团队（现在包括代理）在Cloudflare开发者平台上构建应用，拥有合适的访问控制对于安全发布至关重要。毕竟，你最不希望看到的是代理因为被授予了超出需求的权限，而擅自对生产环境做出更改。

现在，你可以为团队成员或代理授予特定Worker的访问权限，使他们只能对该应用进行修改，而无法访问账户中的其他资源。此外，我们新增了四种角色，让你可以精确限制他们的操作权限：

| 角色 | 允许的操作 | 使用场景 | |------------------|--------------------------------------------------------------------------|--------------------------------------------------------------------------| | 元数据只读 | 查看资源列表、设置和可观测性数据（如指标、日志和追踪），但无法访问产品内容。 | 当你需要让团队成员或代理访问可观测性数据以调试问题，但又不想让他们接触源代码时。 | | 内容只读 | 读取产品内容（如Worker代码或D1数据库内容），但无法修改。 | 当你需要让团队成员或代理访问源代码，但又不希望他们对Worker做出任何更改时。 | | 编辑器 | 读取和写入产品内容，更新设置。无法创建或删除资源。 | 当你需要让团队成员、代理或CI/CD系统部署Worker更改，但希望防止他们删除Worker时。 | | 管理员 | 对资源拥有完全控制权限，包括创建、重命名、删除和授予其他用户访问权限。 | 当你需要让团队成员或代理对Worker拥有完全访问权限（包括删除权限），但不想授予他们访问账户中其他Worker或资源的权限时。 |

新角色现已向所有客户开放。你可以将其分配给特定用户，当他们登录仪表板时，将只能看到你授予他们访问权限的Worker。或者，你可以创建一个具有范围权限的API令牌，将其提供给代理，确保他们只能访问该应用。

以下是创建具有Worker级权限的API令牌的示例：

为团队构建方式设计的角色

在定义这些角色时，我们力求找到合适的平衡点。过于宽泛的角色会迫使你授予超出预期的权限，违背最小权限原则；而过多的个体权限则会让人难以判断该授予哪些权限。我们最终确定了四种角色，它们反映了你可能希望授予人员或代理的访问级别：仅能调试资源而不暴露其内容、仅能阅读内容而不能修改、仅能修改而不能删除资源，或完全管理资源。

我们计划在将资源级访问控制扩展到其他开发者平台产品（包括D1、R2和KV）时使用这些相同的角色。每个角色都可以在三个作用域之一中应用。例如，如果你设置“元数据只读”控制，不同层级的权限将如下所示：

• 开发者平台层级：访问所有开发者平台资源的元数据。

• 产品级：可访问某一产品所有资源的元数据，例如每个 Worker。

• 资源级：可访问某一特定资源的元数据，例如某个 Worker。

角色和权限范围决定了某人可以执行的操作以及可以操作的资源。让我们看看这些权限在一些常见 Worker 工作流程中的具体表现。

在不暴露源代码的情况下进行调试

为排查问题，工程师或代理可能需要查看 Worker 的设置、指标、日志和追踪信息以了解问题所在。但他们不需要查看 Worker 的代码或对其进行修改。

元数据只读权限允许他们访问这些信息而无需暴露 Worker 的源代码。他们可以通过 GraphQL API 查询分析数据、访问日志并检查追踪和其他可观测性数据。这些请求仅返回他们有权访问的 Worker 的数据。如果代理仅限于某个 Worker，它可以通过 Cloudflare API 调查问题，而不会看到账户中其他 Worker 的数据。

随着我们将这些角色扩展到更多开发者平台产品，我们计划保持这种隔离性。某人可以检查 D1 数据库或 R2 存储桶的设置和可观测性数据，而无需读取数据库中的值或存储桶中的文件。

在不修改代码的情况下审查代码

同事或代码审查代理可能需要阅读运行在 Worker 中的代码以了解其工作原理、调查错误或审查提议的更改。但这并不意味着他们应该能够部署新代码或更新 Worker 的设置。

内容只读权限提供了这种隔离。它允许他们检索并审查 Worker 的代码，而无法对其进行修改或部署。当限定到某个特定 Worker 时，他们只能阅读该 Worker 的代码，而不是账户中所有 Worker 的代码。

一旦支持其他开发者平台产品，内容只读权限将采用相同方式工作：某人可以读取 D1 数据库、KV 命名空间或 R2 存储桶中存储的数据，而无法对其进行修改。

在不给予完全控制权的情况下让 CI 进行部署

CI/CD 工作流只需访问其部署的应用程序。它不应能够修改其他 Worker 或删除自己的 Worker 从而导致应用离线。

通过 Worker 级访问控制，每个工作流可以拥有自己的 API 令牌并具有编辑者角色，仅限于某个 Worker。如果工作流配置错误或令牌泄露，影响将被限制：它只能部署该 Worker 的更改，无法删除它或触碰账户中的其他应用。

使用管理员权限删除 Worker

管理员是您可以授予的最高权限级别。它允许您删除应用程序。您仍然可以将该角色限定到某个特定 Worker，以确保权限不会扩展到账户中的所有 Worker。

路由与自定义域名

您可以向 Worker 添加路由或自定义域名，以指定哪些主机名路由到该应用。例如，Wrangler 文件中的此配置会将 example.com 的流量发送到 Worker：

{
"route"
: {
"pattern"
:
"example.com/*"
,
"zone_name"
:
"example.com"
}
}

由于更改该路由可能会重定向生产流量或使应用离线，仅访问 Worker 本身是不够的。要添加、更改或删除路由或自定义域名，您需要同时拥有 Worker 的编辑权限以及该区域的 Workers 路由权限。

要求使用Workers路由权限，而非更广泛的区域访问权限，意味着可以在不更改域名其他无关设置的情况下，管理流量如何到达Workers。

一旦配置了路由，只要部署操作不更改该连接，就可以在不访问关联区域或资源的情况下继续部署Workers的新版本。这使得CI/CD系统可以部署应用，而无需赋予其访问域名、数据库或存储的权限。

Workers权限适用于Durable Objects

Durable Objects没有自己的角色或权限。相反，访问Durable Object的权限由实现它的Workers的访问权限决定。要授予某人访问Durable Object的权限，请为其分配该Workers的相应角色。

Metadata Read-Only权限可让他们访问Durable Object的指标、日志和追踪信息，但无法访问对象中存储的数据。由于Durable Objects Data Studio可以直接查询和修改存储的数据，因此访问这些数据需要Editor角色。

更清晰的错误提示，明确告知你和代理所需权限

当你为他人分配范围较窄的权限时，他们最终可能会尝试执行没有访问权限的操作。此时，错误信息应明确告知他们所需的权限，避免他们陷入僵局。

除了返回通用的403 Forbidden响应外，我们的API现在还会包含指向相关API文档的链接，你可以在其中查看确切的权限要求。这样，你和代理可以准确确定所需的访问级别，而无需授予不必要的广泛权限。

立即可用

所有客户今天都可以使用Workers级别的访问控制。你可以在Cloudflare仪表板、通过API或使用Terraform进行配置。

要为团队成员授予特定Workers的访问权限，请前往Manage Account > Members，选择成员，然后创建包含所需角色和Workers范围的策略。

通过用户组管理团队访问

如果同一团队或项目中的多人需要相同权限，可以创建用户组，而非为每个人单独分配权限。将策略分配给该组，然后添加相关成员。组内所有成员将自动继承该策略。

替代Workers的旧权限

此前，我们使用以下角色和权限来管理Workers的访问。现在随着开发者平台统一角色集的推出，我们建议使用新角色。

| 旧角色 | 成员/API Token | 推荐新角色 | |---|---|---| | Workers Platform (Read-Only) | 成员 | Developer Platform Content Read-Only | | Workers Platform Admin | 开发者平台管理员 | Workers Scripts Read | | API Token | Workers Scripts Edit | | Workers CI Read | Workers CI Edit | | Workers Observability Read | Workers Observability Edit | | Workers Observability Telemetry Edit | Workers Tail Read |

旧角色和权限没有弃用日期。现有分配将继续有效，我们会在任何弃用前提供提前通知。尽管如此，我们建议开始转向新角色，因为它们支持更细粒度的资源级访问。

接下来是什么？

Workers级别的访问控制是Cloudflare开发者平台更统一授权模型的第一步。

接下来，我们将相同的资源级别访问控制扩展到更多开发者平台产品，包括 KV 命名空间和 D1 数据库等资源。您不再需要授予某人访问账户内所有存储桶或所有数据库的权限，而是可以限定其访问所需的具体资源，并将该访问范围与合适的角色进行绑定。

为 Workers 引入的相同角色权限将适用于这些资源。

查看我们的开发者文档以开始使用。

目录栏

讨论栏

相关标签及社交媒体链接

相关标签

在社交媒体上关注

• Cloudflare

• Dina Kozlov

电子邮件订阅 /think