你可以通过权限策略分配角色和作用域，控制谁可以访问 Developer Platform 资源以及他们可以执行哪些操作。每条策略将定义允许操作的角色，与定义这些操作适用范围的作用域组合在一起。
对于 Developer Platform 产品，作用域可以设置在三个级别：
| 级别 | 作用域 | 适用场景 |
|---|---|---|
| 平台 | 账户上的所有产品 | 你希望授予跨 Workers、R2、D1、KV、Durable Objects、Queues、Workers AI、Vectorize、Hyperdrive 以及其他 Developer Platform 资源的访问权限。 |
| 产品 | 某一产品中的全部资源 | 你希望授予对所有 Worker、所有 R2 存储桶或所有 D1 数据库的访问权限，而不授予其他产品的访问权限。 |
| 资源 | 某一产品中的单个资源 | 你希望授予对特定资源的访问权限，例如单个 Worker 或 R2 存储桶。 |
分配以下角色之一，以定义要授予的权限级别：
| 角色 | 允许的操作 |
|---|---|
| Metadata Read-Only | 查看资源列表、设置、指标、日志和跟踪。无法查看代码、数据或已存储对象等产品内容。 |
| Content Read-Only | 包含 Metadata Read-Only 的全部权限，还可以读取 Worker 代码、D1 数据库行或 R2 对象等产品内容。无法进行更改。 |
| Editor | 包含 Content Read-Only 的全部权限，还可以更新产品内容和设置。无法创建或删除资源。 |
| Admin | 完全控制，包括创建和删除资源。 |
可以通过两种方式授予 Developer Platform 权限：
| 授予类型 | 最适合 | 工作方式 |
|---|---|---|
| 成员和用户组 | 使用仪表板或 API 的人员 | 成员登录仪表板或向 API 进行身份验证时继承权限。 |
| API 令牌 | CI/CD 系统、自动化和服务账户 | 令牌仅获得创建时选择的产品和资源权限。 |
当你将角色分配给成员或用户组时，该权限会在用户使用 Cloudflare 仪表板或 API 时生效。
例如，如果你在平台级别为成员分配 Metadata Read-Only，他们可以查看账户上所有 Developer Platform 产品（Workers、R2、D1 及其他产品）的设置、指标、日志和跟踪，但无法查看代码、数据或已存储对象等产品内容。
如果你在 Workers 产品级别分配 Metadata Read-Only，他们可以查看账户上所有 Worker 的设置和可观测性数据，但对 R2、D1 或其他产品没有任何可见性。
如果你仅为单个 Worker 分配 Metadata Read-Only，他们只能看到该 Worker 的设置和可观测性数据，看不到任何其他 Worker 或其他产品。
如果同一团队或项目中的多人需要相同访问权限，请创建用户组，而不是为每个成员单独分配权限。
将权限策略分配给组，然后添加相关成员。每个成员会自动继承该组的策略。
为需要以编程方式访问 Developer Platform 资源的 CI/CD 流水线、代理、脚本和其他自动化系统使用 API 令牌。
例如，为需要更新并部署 Worker 代码的部署流水线创建具有 Workers Editor 权限的 API 令牌。
API 令牌支持产品级权限，并在可用时支持资源级权限。它们不支持平台级权限。要为 API 令牌授予广泛的 Developer Platform 访问权限，请为令牌所需的每个产品选择产品级权限。
要在 Wrangler 中使用细粒度权限，请使用账户拥有的 API 令牌进行身份验证。
要使用账户拥有的 API 令牌对 Wrangler 进行身份验证，请创建仅包含所需权限的令牌，然后设置这些环境变量：
export CLOUDFLARE_API_TOKEN="<YOUR_API_TOKEN>"
export CLOUDFLARE_ACCOUNT_ID="<YOUR_ACCOUNT_ID>"Wrangler 使用令牌的权限。如果令牌限定到特定 Worker，Wrangler 只能执行该 Worker 允许的操作。
Wrangler 命令所需的权限可能因其管理的内容而不同：
| 你想做的事 | Wrangler 命令示例 | 所需访问权限 |
|---|---|---|
| 部署现有 Worker | wrangler deploy |
限定到该 Worker 的 Editor，或 Workers 产品作用域的 Editor。 |
| 创建新的 Worker | 对尚不存在的 Worker 运行 wrangler deploy |
Workers 产品作用域的 Admin。 |
| 跟踪单个 Worker 的日志 | wrangler tail |
限定到该 Worker 的 Metadata Read-Only，或 Workers 产品作用域的 Metadata Read-Only。 |
| 列出 KV namespace | wrangler kv namespace list |
覆盖 KV 的作用域上的 Developer Platform Metadata Read-Only。 |
| 创建 KV namespace | wrangler kv namespace create |
覆盖 KV 的作用域上的 Developer Platform Admin。 |
| 在部署期间更改 Routes 或 Custom Domains | wrangler deploy |
该 Worker 的 Editor，加上每个受影响 zone 的 Workers Routes Write。 |
要部署带有指向 Workers KV、R2 或 D1 等资源的绑定（binding）的 Worker，你需要对 Worker 拥有 Editor 访问权限。部署 Worker 时，你不需要对绑定的资源拥有单独权限。
仅当你需要直接访问这些资源时才需要绑定资源上的权限，例如读取 KV 键、查询 D1 数据库或列出 R2 对象。
| 使用场景 | 作用域 | 角色 |
|---|---|---|
| 查看所有产品的设置、日志和指标 | 平台 | Metadata Read-Only |
| 读取 Worker 代码但不修改 | Workers 产品 | Content Read-Only |
| 部署任何现有 Worker，无法访问其他产品 | Workers 产品 | Editor |
| 在部署期间更改 Routes 或 Custom Domains | Workers 产品和每个受影响的 zone | Editor 以及 Workers Routes Write |
| 重命名现有 Worker | 单个 Worker 或 Workers 产品 | Editor |
| 创建或删除 Worker | Workers 产品 | Admin |
| 来自 CI/CD 或代理的自动部署 | 具有 Workers 产品权限的 API 令牌 | Editor |
| 自动部署到某一个 Worker | 具有单个 Worker 权限的 API 令牌 | Editor |