Cloudflare 宣布推出 Cloudflare Access for Workers，这是一套可将 Access 策略直接连接到单个 Worker 应用或账户内所有 Workers 应用的工具。通过这种连接，应用默认置于公司登录之后，无需依赖每位开发者分别记住并配置访问控制措施。
此举正值员工借助人工智能工具更快构建和部署应用之际。Cloudflare 认为，这种速度也可能导致内部应用或私人数据意外发布到公共互联网，因此设计了这些新工具，使保护托管在 Workers 上的应用成为部署流程本身的一部分。
无论访问方式如何保护应用
在 Worker 上启用 Access 后，Cloudflare 会在任何请求到达应用代码之前强制执行身份验证。无论用户是通过自定义域名、路径、workers.dev 子域名还是预览 URL 访问应用，都适用这一规则。
过去，Access 是在主机名层面配置的，这意味着需要为用户可以访问 Worker 的每个域名创建单独的策略。添加新的自定义域名时，必须先更新策略，否则该域名就可能无需身份验证即可访问。而现在，策略会与 Worker 本身关联，从而自动保护与其关联的域名和 URL。
可以根据需要选择保护范围：
- 仅保护预览 URL，包括用于预览的 workers.dev URL 或自定义域名。
- 保护与应用关联的所有主机名，包括自定义域名、路径、workers.dev 域名和预览 URL。
账户层面的默认策略
管理大量 Workers 应用的团队可以在账户层面一次性配置 Access 策略。这样，所有现有和未来的应用从创建之时起就会成为私有应用，同时可以指定策略覆盖预览流量、生产流量，还是两者都覆盖。
仅保护预览的选项可能适用于希望在生产环境中保持应用公开、同时避免暴露开发中版本的应用。Cloudflare 还支持针对特定 Worker 覆盖账户策略，前提是该 Worker 应当公开。
不需要全面策略的用户，也可以直接将 Access 应用到单个 Worker。Worker 界面中的新 Access 选项卡会显示适用于该应用的策略。当存在多个策略时，更具体的策略优先，顺序如下：主机名策略、Worker 策略，然后是账户策略。
应用代码中的用户身份
Access 还可以识别向应用发送每个请求的用户身份，包括其电子邮件地址、姓名和所属群组。Cloudflare 表示，这些数据可用于定制内容、实施权限或记录每位用户的活动。
身份信息显示在 Worker 的 ctx 上下文对象中，具体通过 ctx.access 提供。应用可以调用 ctx.access.getIdentity() 获取已通过身份验证的用户身份，而无需手动执行 JSON Web Token 验证，例如解析令牌、验证其签名和提取其声明。
Access 支持连接组织现有的身份提供商，也可以根据特定电子邮件地址、电子邮件域名或群组限制访问。对于代理，可以通过服务令牌授予访问权限。
本地测试和内部平台
可以使用 wrangler dev 在本地测试身份行为：在 wrangler.jsonc 文件中添加 Access 配置，以模拟已通过身份验证的用户。这样，开发者可以在配置中切换电子邮件地址，并在部署前验证针对每位用户显示的内容是否正确。
Cloudflare 还提供了一个开源的内部平台示例，支持以拖放方式发布静态网站，并默认将每个已发布的 Worker 设为私有。该架构利用 Workers for Platforms，使命名空间内应用的流量通过一个分发 Worker。将 Access 策略放置在该 Worker 上后，通过它发布的应用默认就会成为私有应用。
可用性和技术架构
该功能现已通过控制面板向所有用户开放，同时提供 Cloudflare Access for Workers 文档以便开始使用。这项新能力基于 FL2。FL2 是一个使用 Rust 构建的模块化中间代理，运行在 Cloudflare 的边缘架构上。
为了能够在 Worker 而非主机名层面启用 Access，Cloudflare 将 Workers 的路由与执行分离，并把路由逻辑移到了 Access 之前的阶段。该公司解释说，具有明确定义模块和有序阶段的 FL2 系统帮助其管理这一变更，因为每个部分都会以固定方式声明其输入和输出，从而使编译器能够在重构期间发现阶段之间不恰当的交互。