一键保护你所有的内部 vibe-coded 应用
AI 使得每个团队的员工都能比以往更快地构建应用程序。
但这种速度也正是让每位 CISO 夜不能寐的原因：任何员工都可以构建应用程序，将其部署到公共互联网，并意外暴露内部工作或公司数据。
今天，我们推出新工具，让您轻松保持托管在 Workers 上的应用程序的私密性。您现在可以直接将 Cloudflare Access 应用于某个 Worker 或您账户中的每个 Worker，这样您的应用程序默认位于公司登录之后，无需依赖每个开发者自行设置。
您现在可以：
在账户级别设置策略，确保所有 preview 和生产部署默认位于公司登录之后。
在单个应用程序上设置策略，确保与其关联的每个域都强制进行身份验证，无论其如何部署。
准确查看谁访问了您的应用程序。 直接在您的代码中获取每个已认证用户的电子邮件、姓名和组——无需 JWT（JSON Web Token）验证。
部署一个默认所有部署均为私有的内部平台。 我们开源了一个 example：一个内部静态站点平台，其中部署的每个 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。您希望默认是私有的。
您可以在账户级别设置一次访问策略，那么您账户中的每个 Worker，无论是当前的还是未来的，从创建之时起就是私有的。
您可以选择策略覆盖的范围：仅预览 URL 流量、所有生产流量，或两者兼有。如果您的生产 Worker 有意公开，但您绝不希望正在进行的部署暴露，那么仅预览模式非常有用。
需要某个 Worker 公开吗？可以绕过该 Worker 上的账户级策略。
保护特定 Worker
如果您不需要账户级默认策略，只想锁定某个特定的 Worker，您可以直接对该 Worker 应用 Access。
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": "[email protected]" }
}
}
}
您的 Worker 通过 ctx.access.getIdentity() 获取它
— 返回一个身份对象，其形状与生产环境中获得的一致。在配置中更换电子邮件，即可作为不同用户进行测试。
这意味着您可以验证正确的内容是否显示给正确的用户，而无需在每次更改时都部署并通过 Access 登录。
部署一个默认所有应用程序均为私有的内部平台
如果您管理一个内部平台，员工可以在其中进行原型设计和部署应用程序，您需要确保每个应用程序都是私有的，而无需在每个应用程序上配置访问控制。
Workers for Platforms 允许您大规模部署 Workers。每个 Worker 都位于一个命名空间内，所有指向该命名空间的流量都通过一个入口点：调度 Worker。
在您的调度 Worker 上设置 Access 策略，则通过它部署的每个 Worker 默认都是私有的。
我们还有一个开源示例，您可以在其中部署自己的内部拖放式部署平台——在调度 Worker 上配置一次访问权限，通过它部署的每个站点默认都是私有的。
点击下面的按钮自行部署！
有关完整架构，请参阅我们的 Workers for Platforms 参考架构。
建立在坚实的基础上
此功能得益于 FL2，即新的基于 Rust 的模块化代理，它为 Cloudflare 的边缘网络提供支持。Access 是您应用程序的前门，因此，它传统上在请求管道中所有 Workers 逻辑之前运行。但为了让 Access 应用程序能够针对单个 Worker 本身而不是其主机名，Access 需要知道给定请求将到达哪个 Worker。因此，我们需要拆分 Workers
路由和 Workers
执行，并移动路由逻辑，使其在 Access 之前运行。
在我们基于 NGINX 和 Lua 模块的旧 FL1 系统中，这种更改将是复杂且危险的。产品之间的交互可能很微妙，如果逻辑依赖于另一个产品修改的共享状态，将其移动到请求管道的早期阶段可能不安全。
FL2 使这变得容易。其严格的模块系统将逻辑分离为定义明确、顺序一致的阶段，这些阶段静态声明其输入和输出。我们能够依靠编译器来发现阶段之间任何损坏的交互，并逐步自信地推出这次重构。
立即试用
此功能现已向所有人开放。在仪表板中试用，或阅读
Cloudflare Access for Workers 文档## 致谢
感谢 Jesse Li、Brandon Strittmatter、Kyle Hiller、Kenny Johnson、Matt "TK" Taylor、Brendan Irvine-Broque、Yomna Shousha 和 Mike Aizatsky 为使其成为可能所做的工程和设计工作！