Secure all your internal vibe-coded applications — in one click

一键保护所有内部 vibe 编码的应用程序 | Cloudflare 博客

post

Developer Platform

Developers

Product News

SASE

Zero Trust

AI

Cloudflare Access

Cloudflare Workers

2026年8月14日

一键保护所有内部 vibe 编码的应用程序

Chythra Malapati、Matt Rothenberg 和 Matt Provost

7分钟阅读

复制链接

AI 让每个团队的员工都能以前所未有的速度构建应用程序。

但这种速度也让每位 CISO 夜不能寐：任何员工都可以构建应用程序、将其部署到公共互联网，并意外暴露内部工作或公司数据。

今天，我们推出全新工具，让保护 Workers 上托管的应用程序变得简单。现在你可以直接将 Cloudflare Access 应用到单个 Worker 或账户中的所有 Worker，使应用程序默认通过公司登录进行保护，无需依赖每位开发者自行设置。

现在你可以：

• 在账户层级设置策略，确保所有预览和生产部署默认通过公司登录进行保护。
• 在单个应用程序上设置策略，确保其关联的每个域名都强制执行身份验证，无论部署方式如何。
• 清晰查看访问你应用程序的用户。在代码中直接获取每个已认证用户的邮箱、姓名和所属组，无需 JWT（JSON Web Token）验证。
• 部署一个内部平台，使所有部署默认为私有。我们已开源示例：一个内部静态站点平台，其中每个部署的 Worker 默认为私有。

Workers 上的访问控制：工作原理

当你在 Worker 上启用 Access 时，Cloudflare 会在任何请求到达应用程序代码之前强制执行身份验证。无论请求如何到达你的 Worker（通过自定义域名、路由、workers.dev 子域名或预览链接），只要启用了 Access，用户都必须先完成身份验证。

此前你需要在主机名层级进行配置，这意味着要在 Worker 可访问的每个域名上设置 Access 策略。如果你想为 Worker 添加新自定义域名，需要先更新 Access 策略，否则该主机名将无需身份验证即可访问。现在策略直接绑定到 Worker 本身，因此与该 Worker 关联的任何域名或 URL 都会自动受到保护。你可以选择保护范围：仅预览链接，或所有主机名。

如果你只保护预览链接，该应用程序创建的每个预览链接（无论是 workers.dev 预览链接还是用于预览的自定义域名）在部署新版本时都需要身份验证。如果你选择保护所有主机名，与该 Worker 关联的所有域名都会受到保护，包括自定义域名、路由、workers.dev 子域名和预览链接。

Access 让你能够控制用户如何认证。你可以连接现有的身份提供商，让员工使用现有凭证登录，或限制访问特定邮箱地址、邮箱域名或组。对于代理，可以通过服务令牌授予访问权限。

更多详情请参阅 Cloudflare Workers 的 Access 文档。

你可以在账户层级一次性设置访问策略，此后账户中所有当前和未来的Worker在创建时都会默认处于私有状态。

你可以选择策略的适用范围：仅预览URL流量、所有生产环境流量，或两者都包含。如果生产环境Worker需要公开访问，但又不希望预览部署内容被意外暴露，"仅预览"模式会非常有用。

需要某个Worker公开访问？可以绕过账户级策略，单独为该Worker设置例外。

保护特定Worker

如果不需要账户级默认策略，只想锁定某个特定Worker，可以直接为该Worker单独设置访问权限。

Worker视图中的新"访问"标签页会明确显示适用于该应用的策略。如果有多个策略，优先级规则为：主机名策略 > Worker策略 > 账户策略。

查看访问你应用的用户信息

当启用访问控制后，你可以获取每个请求的用户信息（包括邮箱、姓名和所属组），从而实现个性化展示、权限控制或按用户记录操作日志。

这通过Worker的上下文对象(ctx)实现。每个请求都会携带包含请求元数据的ctx对象。当启用访问控制时，我们会将认证用户的身份信息附加到ctx.access属性中。你可以通过ctx.access.getIdentity()获取用户的邮箱、姓名等信息。

此前你需要自行验证JWT（解析令牌、验证签名、提取声明），现在当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()获取请求用户的信息（包括邮箱、姓名和所属组）。

在使用wrangler dev进行本地开发时，可以通过在wrangler.jsonc中添加访问配置块来模拟认证用户：

{
"access"
: {
"dev"
: {
"aud"
:
"my-app"
,
"identity"
: {
"email"
:
"[email protected]"
}
}
}
}

你的Worker会通过ctx.access.getIdentity()获取到这个配置信息，返回的identity对象结构与生产环境完全一致。只需修改配置中的邮箱地址，即可模拟不同用户进行测试。

这意味着你可以在不实际部署和通过访问控制登录的情况下，验证内容是否正确显示给对应用户。

部署内部平台实现应用默认私有

如果你需要管理一个内部平台，让员工可以快速原型开发和部署应用，需要所有应用默认私有，而无需为每个应用单独配置访问控制。

Workers for Platforms功能让你可以规模化部署Worker。每个Worker都位于一个命名空间内，所有流量通过该命名空间的单一入口点：调度Worker。

为你的调度Worker设置访问策略后，通过该调度Worker部署的所有Worker都会默认处于私有状态。

我们还有一个开源示例，您可以通过它部署自己的内部拖放式部署平台 —— 一旦在分发器工作节点上配置访问权限，所有通过该平台部署的站点默认均为私有。

点击下方按钮亲自部署试试！

如需了解完整架构，请参阅我们的《适用于平台的Workers参考架构》。

建立在稳固基础上

这项功能得益于FL2，这是Cloudflare边缘的新一代基于Rust的模块化代理。访问控制是应用的前端入口，因此传统上它会在请求管道中所有Workers逻辑之前执行。但为了使Access应用能够直接针对单个Workers而非其主机名，Access需要知道每个请求的目标Workers。因此，我们需要将Workers路由与Workers执行分离，并将路由逻辑提前到Access之前执行。

在我们基于NGINX和Lua编写的旧版FL1系统中，这种变更会非常复杂且充满风险。产品间的交互可能微妙，如果某个逻辑阶段依赖其他产品修改的共享状态，提前执行可能会带来安全隐患。

FL2让这一切变得简单。其严格的模块系统将逻辑划分为定义明确、顺序一致的阶段，并静态声明输入输出。我们得以借助编译器识别各阶段之间可能存在的交互问题，并逐步自信地推进此次重构。

立即体验

现在所有人都可以使用该功能。您可以在仪表板中直接体验，或阅读《Workers的Cloudflare Access文档》开始使用。

致谢

感谢Jesse Li、Brandon Strittmatter、Kyle Hiller、Kenny Johnson、Matt "TK" Taylor、Brendan Irvine-Broque、Yomna Shousha和Mike Aizatsky的工程和设计工作，使这一切成为可能！

目录栏

讨论栏

相关标签及社交媒体链接

相关标签

关注社交媒体

• Cloudflare

• Chythra Malapati

• Matt Rothenberg

• Matt Provost

电子邮件订阅