Cloudflare 为 Workers 增加一键 Access
Cloudflare AI··作者 Matt Provost
关键信息
Cloudflare 表示，Access 会在任何请求到达 Worker 代码之前强制认证，因此无论应用通过什么方式访问，认证都发生在边缘侧。策略可以只覆盖预览流量，也可以覆盖所有主机名；当账户、Worker 和主机名规则重叠时，优先级更具体的策略会生效。
资讯摘要
Cloudflare 表示，AI 让员工能够更快地构建和发布应用，但这种速度也带来了安全隐患：内部工具可能在没人来得及配置保护之前，就已经被部署到公网。为了解决这个问题，Cloudflare 正在推出新工具，让用户可以直接把 Cloudflare Access 应用到 Workers 上。新的方式既可以保护单个 Worker，也可以保护账户中的所有 Worker，从而让应用默认处于公司登录后才能访问的状态，而不是依赖每个开发者手动配置认证。Cloudflare 说，这种策略可以按需覆盖预览部署、生产部署，或者两者都覆盖。
它还意味着，与某个 Worker 相关的任何域名都能自动受到保护，包括路由、自定义域名、workers.dev 子域名和预览链接。此前，Access 必须在主机名层面配置，这意味着一旦新增或修改域名，就需要单独更新策略，否则可能会留下未认证访问入口。现在策略是附加在 Worker 本身上的，因此即使域名或路由发生变化，也不必重新搭建安全设置。Cloudflare 还表示，经过认证的用户邮箱、姓名和组信息可以直接在代码中使用，而且公司已经开源了一个内部静态站点平台示例，其中每个 Worker 部署都会默认保持私有。
资讯正文
AI 让各个团队的员工都能比以往任何时候更快地构建应用程序。
但正是这种速度，也让每一位 CISO 夜不能寐：任何员工都可以构建一个应用程序，将其部署到公共互联网，并意外暴露内部工作内容或公司数据。
今天，我们推出了新的工具，让你可以轻松将托管在 Workers 上的应用程序保持私密。你现在可以直接将 Cloudflare Access 应用于某个 Worker，或应用于你账户中的每一个 Worker，这样你的应用程序默认就位于公司的登录认证之后，而不必依赖每位开发者自己去设置。
你现在可以：
- 在账户级别设置策略，确保所有预览环境和生产环境部署默认都位于公司登录认证之后。
- 为单个应用程序设置策略，确保无论如何部署，其关联的每个域名都强制进行身份验证。
- 准确查看谁访问了你的应用程序。你可以直接在代码中获取每一位已认证用户的邮箱、姓名和所属组——无需进行 JWT（JSON Web Token）验证。
- 部署一个内部平台，让每次部署默认都是私密的。我们开源了一个示例：一个内部静态网站平台，其中部署的每个 Worker 都是私有的。
Workers 上的 Access：它是如何工作的
当你在某个 Worker 上启用 Access 时，Cloudflare 会在任何请求到达你的应用程序代码之前强制进行身份验证。请求是如何到达你的 Worker 的并不重要，无论是通过自定义域名、路由、workers.dev 子域名，还是预览 URL；只要启用了 Access，用户就必须先完成身份验证。
此前，你必须在主机名级别进行配置，这意味着需要在你的 Worker 可访问的每个域名上分别设置 Access 策略。如果你想为你的 Worker 添加一个新的自定义域名，你需要先更新 Access 策略，否则该主机名将无需身份验证即可访问。
现在，这项策略是绑定到 Worker 本身的，因此与该 Worker 关联的任何域名或 URL 都会自动受到保护。你可以选择要保护的范围：仅预览 URL，或者所有主机名。
如果你将其设置为仅预览，那么为该应用程序创建的每一个预览 URL，无论是 workers.dev 预览 URL 还是你用于预览的自定义域名，在你部署新版本时都需要进行身份验证。如果你将其设置为所有主机名，那么与该 Worker 关联的每一个域名都会受到保护——自定义域名、路由、workers.dev 子域名以及预览 URL。
Access 让你能够控制用户如何进行身份验证。你可以连接现有的身份提供商，这样员工就能使用他们已经在用的凭据登录；也可以将访问权限限制为特定的邮箱地址、邮箱域名或组。对于代理，你可以通过服务令牌授予访问权限。
你可以在这里阅读 Cloudflare Access for Workers 文档了解更多信息。
默认将账户中的每个 Worker 都设为私有
如果你所在组织中有开发者在部署 Workers，你不希望依赖每个人都记得启用 Access。你希望默认状态就是私有。
你可以在账户级别一次性设置 Access 策略，并且你账户中的每个 Worker——无论是当前的还是未来新建的——从创建那一刻起就都是私有的。
你可以选择该策略覆盖的范围：仅预览 URL 流量、所有生产流量，或者两者都包括。仅预览模式在你的生产 Workers 本来就有意公开、但你又不希望任何正在进行中的部署被暴露时非常有用。
如果需要某个 Worker 对外公开？你可以绕过该 Worker 上的账户级策略。
保护特定 Worker
如果你不需要账户级默认设置，只想锁定某一个特定 Worker，也可以直接将 Access 应用于该 Worker。
Worker 视图中的新 Access 选项卡会准确显示哪些策略适用于该应用。如果你同时配置了多个策略，最具体的那个会优先：先是主机名策略，然后是 Worker 策略，最后是账户策略。
查看是谁在访问你的应用
当 Access 正在保护你的 Worker 时，你可以获取每个请求的发起者信息——他们的电子邮件、姓名和所属组——从而个性化他们看到的内容、执行权限控制，或者按用户记录活动日志。
这项功能通过 Worker 的上下文对象（ctx）实现。发往 Worker 的每个请求都会携带一个 ctx，其中包含该请求的元数据。当启用 Access 时，我们会把经过认证的用户身份附加到其中，作为 ctx.access。随后，调用 ctx.access.getIdentity() 就能获取用户的电子邮件、姓名等信息。
在此之前，这意味着你需要自己验证 JWT——解析令牌、验证签名，并提取声明。现在，当你的 Worker 启用 Access 后，每个经过身份验证的请求都会包含 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() 获取这些信息——返回一个与你在生产环境中得到的身份对象相同结构的对象。把配置中的 email 改掉，就可以用不同用户身份进行测试。
这意味着你可以在不必每次改动都部署并通过 Access 登录的情况下，验证正确的内容是否会展示给正确的用户。
部署一个内部平台，让每个应用默认都是私有的
如果你管理的是一个内部平台，员工可以在上面进行原型设计并部署应用，那么你需要确保每个应用默认都是私有的，而不必为每个应用单独配置访问控制。
Workers for Platforms 允许你大规模部署 Workers。每个 Worker 都位于一个命名空间中，而该命名空间的所有流量都通过一个单一入口点：dispatch Worker。
为你的 dispatch Worker 设置一条 Access policy，所有通过它部署的 Worker 默认都是私有的。
我们还提供了一个开源示例，你可以部署自己的内部拖放式部署平台——只需在 dispatcher worker 上配置一次访问权限，之后通过它部署的每个站点默认都会是私有的。
点击下方按钮即可自行部署！
有关完整架构，请参阅我们的 Workers for Platforms 参考架构。
建立在坚实基础之上
这一功能之所以成为可能，得益于 FL2——Cloudflare 边缘网络背后的新一代、基于 Rust 的模块化代理。Access 是应用的前门，因此传统上它会在请求流水线中的所有 Workers 逻辑之前运行。但为了让 Access 应用能够直接面向单个 Worker，而不是它们的主机名，Access 需要知道某个请求最终会到达哪个 Worker。因此，我们需要将 Workers 路由与 Workers 执行拆分开来，并把路由逻辑前移，这样它才能在 Access 之前运行。
在我们旧的 FL1 系统中，基于 NGINX 和用 Lua 编写的模块，这种改动会非常复杂且风险很高。不同产品之间的交互可能十分微妙，而如果某段逻辑依赖于被另一个产品修改的共享状态，那么把它移到请求流水线更早的阶段运行就可能不安全。
FL2 让这一切变得很容易。它严格的模块系统将逻辑拆分为定义明确、顺序一致的多个阶段，这些阶段会静态声明自己的输入和输出。我们得以借助编译器发现各阶段之间任何损坏的交互，并自信地逐步推出这次重构。
今天就来试试
现在这项功能已向所有人开放。你可以在控制台里试用，或者阅读 Cloudflare Access for Workers 文档开始上手。
致谢
感谢 Jesse Li、Brandon Strittmatter、Kyle Hiller、Kenny Johnson、Matt “TK” Taylor、Brendan Irvine-Broque、Yomna Shousha 和 Mike Aizatsky 为实现这一切所做的工程和设计工作！
来源与参考
收录于 2026-08-15