Cloudflare 在 8 月 14 日发了一篇讲 Access for Workers 的文章，作者是 Chythra Malapati、Matt Rothenberg 和 Matt Provost。这次更新解决了一个实际痛点：以前给 Worker 加登录保护，得在每个域名上分别配 Access 策略；现在策略可以直接附在 Worker 本身，所有关联的域名、路由、workers.dev 子域和预览 URL 自动受保护。
策略附着在 Worker 而不是域名
旧的流程是在 Cloudflare Access 里按主机名配策略。如果你的 Worker 跑在自定义域名 app.example.com 上，就得为这个域名单独配一条规则。后来又加了一个路由 internal.example.com/api，又得加一条。预览 URL 每次部署都变，根本配不过来。
新机制把策略附在 Worker 上。你在 Worker 设置里选择保护范围，可以是只保护预览 URL，也可以是所有主机名。选了「所有主机名」，那么这个 Worker 能收到请求的每条路径、每个域名、每个 workers.dev 子域，全部要求身份验证才放行。
文章给出的示意图显示，Access 检查发生在请求到达 Worker 代码之前。用户访问任何指向这个 Worker 的 URL，Cloudflare 先拦下来，跳转到你配置的身份提供商（比如公司的 SSO），验证通过后才把请求转发给 Worker。Worker 代码本身不需要写任何鉴权逻辑。
三个层级的策略优先级
你可以在三个地方配 Access 策略：
- 账户级别：一次配置，账户下所有 Worker 都受保护。适合公司内部平台，默认全部私有，个别需要公开的 Worker 再单独豁免。
- Worker 级别：只保护某一个 Worker，其他 Worker 不受影响。
- 主机名级别（旧方式依然可用）：针对某个具体域名配策略。
当一个请求同时匹配多条策略时，优先级是主机名策略 > Worker 策略 > 账户策略。文章提到，如果你设了账户级的默认保护，但某个 Worker 需要公开访问（比如对外的 API），可以在那个 Worker 上勾选「bypass account policy」跳过账户策略。
这个设计让内部平台的场景变得可行。Cloudflare 开源了一个模板项目（https://github.com/cloudflare/templates/tree/main/internal-sites-template），演示如何搭一个静态站点平台，每个部署上去的站点自动是私有的，不需要开发者自己记得加保护。
ctx.access.getIdentity() 拿到用户信息
开启 Access 之后，每个请求的 ctx 对象会多一个 access 属性。你在 Worker 代码里调 ctx.access.getIdentity()，就能拿到已认证用户的邮箱、姓名、所属组等信息。这些信息来自你配置的身份提供商，比如 Google Workspace、Okta 或 Azure AD。
文章给出的代码片段：
export default {
async fetch(request, env, ctx) {
if (!ctx.access) {
return new Response('Access required', { status: 403 });
}
const identity = await ctx.access.getIdentity();
return new Response('Hello ' + identity.email);
}
};以前要拿用户信息，得手工验证 JWT：从请求头或 Cookie 里提取 token，用 Cloudflare 的公钥验证签名，解析 payload 拿到 claims。现在 Cloudflare 帮你验证完了，ctx.access 里的 identity 保证是合法的。
文章没展开讲 identity 对象的完整结构，但提到里面包含 email、name 和 groups，还有更多字段可以参考文档。拿到 groups 之后，你可以在 Worker 里做细粒度的权限控制，比如只允许 engineering 组访问某个路径。
预览环境默认保护
文章反复提到的一个场景是预览 URL。Cloudflare Pages 和 Workers 的预览部署会生成一个随机子域名，开发者拿来做内部测试。问题是这个 URL 虽然随机，但只要别人知道了，就能直接访问。如果预览版本连着公司内网数据库，或者展示了还没发布的功能，泄露出去就是安全事故。
新的 Access for Workers 允许你在账户级别设一条策略，只保护预览流量。生产环境的 Worker 可以保持公开，但所有预览部署自动要求登录。这个设置在 Zero Trust 控制台的 Account Access Policies 里，选择 Preview traffic only。
如果你的公司有几十个团队各自部署 Worker，不可能指望每个人都记得给预览环境加保护。账户级策略让安全团队配一次，全公司的预览环境都受保护，开发者无感知。
我关心的两个问题
文章没说的是性能开销。每个请求都要先跳转到身份提供商验证，验证通过后再回到 Cloudflare，这一来一回的延迟是多少？对于内部工具来说可能无所谓，但如果是对延迟敏感的 API，多出来的几百毫秒可能就不能接受了。
另一个是 service token。文章提到 for agents you can grant access through service tokens，但没展开讲怎么配。实际场景里经常有自动化脚本或 CI/CD 流程需要调用内部 API，这些调用没法走浏览器登录流程，必须用 token 认证。我猜 service token 是在 Access 里单独配的一种凭证，但不知道 Worker 代码里能不能区分出请求是来自真人还是 service token。
为什么现在做这个
文章开头说 AI has enabled employees across every team to build applications faster than ever before，但紧接着指出这也是 CISO 最头疼的：任何员工都能用 AI 写个应用，部署到公网，不小心就把内部数据暴露了。
这个说法我认同一半。问题不是 AI 让开发变快了，而是 Workers 这类平台本身就降低了部署门槛。以前要发布一个应用，得过运维那一关，至少有人会问这东西要不要加登录。现在一个 wrangler deploy 就上线了，中间没有任何检查点。
Access for Workers 实际上是在弥补这个缺口。当部署变得零摩擦，安全控制就得内置到平台里，而不是依赖开发者自觉。账户级的默认保护策略，本质上是把默认私有变成基础设施的一部分。