Cloudflare Launches Direct Cloudflare Access Integration for Workers

Cloudflare Launches Direct Cloudflare Access Integration for Workers Cloudflare has introduced new controls allowing Cloudflare Access policies to attach directly to individual Workers or globally across an entire account, ensuring internal applications and preview deployments remain authenticated by default. Access policies can now attach directly to Workers or accounts, rather than requiring setup on each individual hostname. Policies can protect either preview URLs exclusively or all associated hostnames, routes, and custom domains. User identity metadata is automatically injected into the Worker context object as ctx.access, removing the need for manual JWT parsing. The functionality is enabled by FL2, Cloudflare's Rust-based modular proxy, which decoupled Worker routing from Worker execution. Worker-Level and Account-Wide Access Policies Previously, administrators had to configure Cloudflare Access policies separately for each hostname or custom domain attached to a Worker. Policies can now attach directly to individual Workers or across an entire account, guaranteeing that all current and future deployments are secured by default. Administrators can choose to protect all hostnames or restrict protection strictly to preview URLs, and can selectively bypass account-wide policies on individual public Workers. If multiple rules apply, the most specific policy takes priority: hostnames first, followed by Worker-level, then account-level rules. Runtime Identity Integration and Local Emulation When Access protects a Worker, Cloudflare automatically verifies authentication and attaches user identity information to the Worker execution context under ctx.access. Developers can query user attributes such as name, email, and groups directly via ctx.access.getIdentity(), eliminating the requirement to manually parse and verify JWTs. For local workflows with wrangler dev, developers can configure an access block in wrangler.jsonc to simulate authenticated user identities without needing to deploy or repeatedly log in. Dispatch Workers and Edge Architecture Changes For scaled environments using Workers for Platforms, applying an Access policy to a single dispatch Worker automatically protects all child Workers within that namespace. Delivering Worker-level protection required moving Worker routing ahead of Access in the edge request pipeline, while keeping Worker execution downstream. Cloudflare implemented this routing separation using FL2, its Rust-based modular proxy, which replaced the previous NGINX and Lua-based architecture with statically declared phases to prevent unsafe cross-product state interactions.

Cloudflare 为 Workers 推出一键式 Access 访问控制与默认私有化保护 Cloudflare 宣布推出新工具，支持将 Cloudflare Access 直接应用于单个 Worker 或账户下的所有 Worker，无需在每个主机名上分别配置即可实现默认身份验证与私有化访问控制。 策略现直接挂载至 Worker 本身，无论通过自定义域名、路由、workers.dev 子域还是预览 URL 访问，均在到达应用代码前强制身份验证。 支持账户级全局策略，所有当前及未来新建的 Worker 默认保持私有，也可按需针对单个 Worker 进行绕过或单独加锁。 Worker 可通过 ctx.access.getIdentity() 直接获取认证用户的邮箱、姓名及分组等元数据，免去手动解析和校验 JWT 的步骤。 底层基于 Cloudflare 新一代 Rust 代理 FL2，通过拆分 Worker 的路由与执行阶段，实现了先确定目标 Worker 再执行 Access 鉴权的能力。 Worker 级别与账户级别的访问控制 以往用户必须在各个主机名层面配置 Access 策略，一旦新增自定义域名若未同步更新就可能导致未授权公开访问。新功能将策略与 Worker 实体绑定，用户可选择保护所有主机名或仅保护预览 URL。此外，企业可在账户层级设定统一策略，确保所有现有及未来新建的 Worker 默认私有化；若特定应用需要公开，也可针对单个 Worker 设置策略绕过。多层策略冲突时，优先级按“主机名 > Worker > 账户”执行。 简化身份提取与本地开发调试 当开启 Access 保护后，请求上下文对象会直接注入 ctx.access。开发者无需再手动解析 JWT 签名和声明，调用 ctx.access.getIdentity() 即可读取请求者的邮箱、姓名与权限组信息。在本地使用 wrangler dev 调试时，开发者可通过在 wrangler.jsonc 中添加 access 字段来模拟不同登录用户，无需频繁部署上线即可验证权限与内容呈现。 平台集成与 FL2 架构支持 针对 Workers for Platforms 这类内部部署平台，管理员只需在入口处的 dispatch Worker 上配置一次 Access，即可使该命名空间下部署的所有站点默认私有。该能力的实现依赖于 Cloudflare 基于 Rust 开发的新一代代理系统 FL2。由于旧有架构难以在 Access 前安全分离逻辑，FL2 的模块化阶段系统成功将 Workers 的路由与执行拆分开来，使系统能在 Access 鉴权发生前提前判定目标 Worker。

AI has enabled employees across every team to build applications faster than ever before. But that speed is also what's keeping every CISO up at night: any employee can build an application, deploy it to the public Internet, and accidentally expose internal work or company data. Today, we're launching new tools to make it easy to keep your applications hosted on Workers private. You can now apply Cloudflare Access directly to a Worker or to every Worker in your account, so that your applications are behind your company login by default, without relying on each developer to set that up themselves. You can now: When you enable Access on a Worker, Cloudflare enforces authentication before any request reaches your application code. It doesn't matter how the request gets to your Worker, whether it's through a custom domain, a route, a workers.dev subdomain, or a preview URL. If Access is on, the user has to authenticate first. Previously, you had to configure this at the hostname level, which meant setting up Access policies on each domain your Worker was reachable on. If you wanted to add a new custom domain to your Worker, you needed to update the Access policy first or that hostname would be reachable without authentication. Now the policy is attached to the Worker itself, so any domain or URL associated with that Worker is automatically protected. You can choose what to protect: just preview URLs, or all hostnames. If you set it to previews only, every preview URL created for that application, whether it's a [workers.dev](http://workers.dev) preview URL or a custom domain you use for previews, will require authentication whenever you deploy a new version. If you set it to all hostnames, every domain associated with that Worker is protected — custom domains, routes, [workers.dev](http://workers.dev) subdomains, and preview URLs. Access gives you control over how users authenticate. You can connect your existing identity provider, so employees sign in with the credentials they already use, or restrict access to specific email addresses, email domains, or groups. For agents, you can grant access through service tokens. Read more in the [Cloudflare Access for Workers documentation](http://developers.cloudflare.com/workers/configuration/cloudflare-access/) here. If you have developers across your organization deploying Workers, you don't want to rely on each one to remember to enable Access. You want the default to be private. You can set an Access policy once at the account level, and every Worker in your account, current and future, is private from the moment it's created. You choose what the policy covers: only preview URL traffic, all production traffic, or both. Preview-only is useful if your production Workers are intentionally public, but you never want an in-progress deployment exposed. Need a Worker to be public? Bypass the account-wide policy on that one Worker. If you don't need an account-wide default and just want to lock down one specific Worker, you can apply Access to that Worker directly. The new Access tab in the Worker view shows exactly which policies apply to that application. If you have multiple, the most specific one takes priority: hostname policies first, then Worker policies, then account policies. When Access is protecting your Worker, you can get information about who is making each request — their email, name, and groups — so you can personalize what they see, enforce permissions, or log activity per user. This works through your [Worker's context object (ctx)](https://developers.cloudflare.com/workers/runtime-apis/context/). Every request to your Worker carries a ctx with metadata about that request. When Access is enabled, we attach the authenticated user's identity to it as ctx.access. From there, call `ctx.access.getIdentity()` to get back the user's email, name, and [more](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/application-token/). Before, this meant validating a JWT yourself — parsing the token, verifying the signature, and extracting the claims. Now, when Access is enabled on your Worker, every authenticated request includes ctx.access. Here's all you need to get the user's identity: We showed how you can use `ctx.access.getIdentity()` to give your Worker information about who is making a request — their email, name, and groups. You can use this when developing locally with wrangler dev. Add an access block to your `wrangler.jsonc` to simulate an authenticated user: Your Worker picks it up through `ctx.access.getIdentity()` — returning an identity object shaped like what you'd get in production. Swap the email in your config to test as a different user. This means you can verify that the right content shows up for the right user without having to deploy and sign in through Access every time you make a change. If you manage an internal platform where employees can prototype and deploy applications, you need every application to be private without configuring access controls on each one. [Workers for Platforms](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/) lets you deploy Workers at scale. Every Worker lives inside a namespace, and all traffic to that namespace goes through a single entry point: the dispatch Worker. Set an Access policy on your dispatch Worker, and every Worker deployed through it is private by default. We also have an [open-source example](https://github.com/cloudflare/templates/tree/main/internal-sites-template) where you can deploy your own internal drag-and-drop deployment platform — configure access on the dispatcher worker once and every site deployed through it is private by default. Click the button below to deploy it yourself! For the full architecture, see our [Workers for Platforms reference architecture.](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/) This feature was made possible by FL2, the new [Rust-based modular proxy](https://blog.cloudflare.com/20-percent-internet-upgrade/) that powers Cloudflare's edge. Access is the front gate to your applications, and as such, it traditionally ran before all Workers logic in the request pipeline. But in order for Access applications to target individual Workers themselves instead of their hostnames, Access needs to know which Worker a given request is destined to reach. Therefore, we needed to split Workers *routing* from Workers *execution*, and move the routing logic, so it could run before Access. In our old FL1 system based on NGINX and modules written in Lua, this change would have been complex and risky. Interactions between products can be subtle, and moving logic to an earlier phase of the request pipeline can be unsafe if it depends on shared state that is modified by another product. FL2 made it easy. Its strict module system separates logic into well-defined, consistently ordered phases that statically declare their inputs and outputs. We were able to lean on the compiler to surface any broken interactions between phases, and gradually roll out this refactor with confidence. This is now available to everyone. Try it out in the [dashboard](https://dash.cloudflare.com/account/workers-and-pages) or read the [Cloudflare Access for Workers documentation](http://developers.cloudflare.com/workers/configuration/cloudflare-access/) to get started. Thank you to Jesse Li, Brandon Strittmatter, Kyle Hiller, Kenny Johnson, Matt "TK" Taylor, Brendan Irvine-Broque, Yomna Shousha, and Mike Aizatsky for the engineering and design work that made this possible!