Cloudflare Access for Workers 上线：一键把全员 vibe coding 应用挡在公司登录之后

林知秋AI 前沿2026-09-181217 阅读💛 108 收藏

一句话结论

Cloudflare Access for Workers 正式上线：把 Access 策略直接挂到 Worker 或整个账户上，员工用 AI 搭的内部应用从部署那一刻起就在公司登录墙后面，自定义域名、路由、workers.dev 子域、预览 URL 全部自动覆盖，不再依赖每个开发者自觉配置。这是 AI 编程普及后，企业把”影子应用”关进笼子的一键式方案。

Cloudflare Access for Workers 发布主视觉

AI 编程提速，安全问题跟着提速

AI 让每个团队的员工都能以前所未有的速度开发应用。但这正是让每个 CISO 夜不能寐的原因：任何员工都能构建应用、部署到公网，并可能意外暴露内部工作成果或公司数据。

今天 Cloudflare 发布新工具，让 Workers 上托管的应用轻松保持私有：可以把 Access 直接套用到单个 Worker，或账户里的每一个 Worker，让应用默认处于公司登录之后，无需依赖每个开发者自己去设置。

现在你可以：

在账户级设一条策略，确保所有预览和生产部署默认处于公司登录之后。
对单个应用设策略，无论它以何种方式部署，认证在其所有关联域名上强制生效。
精确看到谁在访问你的应用：在代码里直接拿到每个认证用户的邮箱、姓名和所属组，无需 JWT（JSON Web Token）验证。
部署一个默认私有的内部平台：Cloudflare 开源了一个内部静态站点平台示例，其中每个 Worker 部署后都是私有的。

Access on Workers 的工作原理

在 Worker 上启用 Access 后，Cloudflare 会在请求到达你的应用代码之前强制完成认证。请求怎么到达 Worker 无所谓——自定义域名、路由、workers.dev 子域还是预览 URL。Access 开着，用户就必须先登录。

Access 策略作用于 Worker 本身的示意

以前这套要在 hostname 层配置，意味着要给 Worker 可达的每个域名分别设 Access 策略。想给 Worker 加个新自定义域名，得先更新 Access 策略，否则那个域名就会裸奔。现在策略直接挂在 Worker 本身上，任何关联域名或 URL 自动受保护。你可以选择保护范围：仅预览 URL，或所有 hostname。

设为”仅预览”时，该应用创建的每个预览 URL——无论是 workers.dev 预览地址还是用于预览的自定义域名——在每次部署新版本时都要求认证。设为”所有 hostname”时，该 Worker 关联的每个域名都受保护：自定义域名、路由、workers.dev 子域和预览 URL。

Access 还让你控制用户如何认证：可以接入现有的身份提供商，让员工用已有凭据登录；也可以把访问限制到特定邮箱、邮箱域名或组。对于 AI 智能体，可以通过服务令牌授权访问。

账户级默认私有：不指望每个开发者记得开锁

如果组织里有很多开发者都在部署 Workers，你不会想依赖每个人记得启用 Access——你要的是默认私有。

在账户级设一次 Access 策略，账户里每个 Worker（现有的和未来的）从创建那一刻起就是私有的。策略覆盖什么由你定：仅预览 URL 流量、全部生产流量，或两者兼有。“仅预览”适合生产 Worker 本来就是公开的场景，但你永远不想让开发中的部署外泄。

账户级 Access 策略配置界面

某个 Worker 确实需要公开？在那一个 Worker 上绕过账户级策略即可。

绕过账户级策略的配置入口

只保护某个特定 Worker

不需要账户级默认、只想锁死一个特定 Worker 时，可以直接对该 Worker 套用 Access。

对单个 Worker 应用 Access 的界面

Worker 视图里新增的 Access 标签页会显示哪些策略作用于该应用。如果有多条，最具体的优先：先是 hostname 策略，然后是 Worker 策略，最后是账户策略。

看清谁在访问你的应用

Access 保护 Worker 时，你可以获取每个请求发起者的信息——邮箱、姓名、所属组——用于个性化展示、权限控制或按用户记录活动日志。

实现靠 Worker 的上下文对象（ctx）。到 Worker 的每个请求都携带含请求元数据的 ctx。Access 启用后，认证用户的身份会挂到 ctx.access 上，调用 ctx.access.getIdentity() 即可拿到邮箱、姓名等。

以前这意味着要自己验证 JWT——解析令牌、验签、提取声明。现在 Access 在 Worker 上启用后，每个认证请求自动带 ctx.access。

获取用户身份只需这些：

export default {
  async fetch(request, env, ctx) {
    if (!ctx.access) {
      return new Response("Access required", { status: 403 });
    }

    const identity = await ctx.access.getIdentity();
    const email = identity?.email ?? "unknown";

    return new Response(`Hello, ${email}`);
  }
};

部署前先在本地测试

ctx.access.getIdentity() 让 Worker 知道请求者是谁。本地开发用 wrangler dev 时同样可用：在 wrangler.jsonc 里加一个 access 块模拟认证用户：

{
  "access": {
    "dev": {
      "aud": "my-app",
      "identity": { "email": "admin@company.com" }
    }
  }
}

Worker 会通过 ctx.access.getIdentity() 读取它——返回的身份对象结构与生产环境一致。换掉配置里的邮箱就能以不同用户测试。这意味着不用每次改动都部署再登录验证，就能确认”对的用户看到对的内容”。

部署一个默认全私有的内部平台

如果你管理一个让员工原型化并部署应用的内部平台，你需要每个应用都私有，而不想逐个配置访问控制。

Workers for Platforms 支持大规模部署 Worker。每个 Worker 位于一个命名空间内，到该命名空间的所有流量都经过单一入口：dispatch Worker。给 dispatch Worker 设一条 Access 策略，通过它部署的每个 Worker 默认就是私有的。

内部平台架构：dispatch Worker 作为统一入口

Cloudflare 还开源了一个可自部署的内部拖拽式部署平台示例——在 dispatcher worker 上配置一次 access，通过它部署的每个站点默认私有。点下面的按钮即可自己部署。

开源内部部署平台的一键部署按钮

完整架构见 Workers for Platforms 参考架构。

地基：FL2 模块化代理

这个功能得以实现靠 FL2——Cloudflare 边缘上新的 Rust 模块化代理。Access 是应用的门前守卫，传统上在请求管道中先于所有 Workers 逻辑运行。但要让 Access 直接针对单个 Worker 而非其 hostname，Access 需要知道请求要到达哪个 Worker。因此需要把 Workers 路由从 Workers 执行中拆出来，把路由逻辑提前到 Access 之前。

在旧的 FL1 系统（NGINX + Lua 模块）里，这种改动复杂且危险。产品间交互很微妙，把依赖共享状态的逻辑移到管道更早阶段可能不安全。FL2 让这事变容易了：严格的模块系统把逻辑分进定义清晰、顺序一致的阶段，阶段静态声明输入输出。可以依赖编译器暴露阶段间的坏交互，并放心地灰度推进重构。