Cloudflare Access for Workers: Securing Internal Applications at the Edge
This article introduces Cloudflare Access for Workers, a new feature that simplifies securing internal applications built on Cloudflare Workers. It discusses how policies can be applied at the account, Worker, or hostname level to enforce authentication, abstracting away JWT validation and integrating with existing identity providers. The underlying architectural shift to FL2, Cloudflare's Rust-based modular proxy, enabled this functionality by allowing more flexible routing logic before Access enforcement.
Read original on Cloudflare BlogSimplified Access Control for Serverless Applications
Cloudflare Access for Workers streamlines the process of securing internal applications by attaching authentication policies directly to Workers rather than hostnames. This eliminates the need for developers to manually configure access controls for each deployment URL or custom domain, significantly reducing the risk of accidental data exposure. It centralizes access management, enforcing security at the edge before requests ever reach the application logic.
Policy Enforcement Levels
- Account-level Policies: Enforce authentication for all Workers within an account, present and future, with options to cover preview URLs, production traffic, or both. This establishes a secure-by-default posture.
- Worker-level Policies: Apply specific access rules to an individual Worker, overriding account-level defaults if necessary.
- Hostname-level Policies (Legacy/Specific Override): While the new feature prioritizes Worker-level policies, hostname policies can still be used and take precedence for granular control.
Hierarchical Policy Management
This tiered policy structure (hostname > Worker > account) demonstrates a common system design pattern for hierarchical configuration, allowing for broad defaults while maintaining flexibility for specific overrides. This balance is crucial in managing large-scale deployments.
Architectural Enablers: FL2 and Request Pipeline Reordering
A key architectural change that enabled this feature is the transition to FL2, Cloudflare's new Rust-based modular proxy. Previously, Access ran before Workers logic in the request pipeline, making it difficult for Access to target specific Workers without knowing the request's ultimate destination. With FL2, Cloudflare was able to split Workers routing from Workers execution and move the routing logic to an earlier phase of the request pipeline. This allows Access to identify the target Worker before applying policies, regardless of the hostname used.
struct FL2ModuleSystem {
routing_phase: fn(Request) -> WorkerRoute,
access_enforcement_phase: fn(Request, WorkerRoute) -> AuthResult,
worker_execution_phase: fn(Request, AuthResult) -> Response,
}The strict module system of FL2, with its well-defined, consistently ordered phases and static declaration of inputs/outputs, was critical. This allowed engineers to safely refactor the request pipeline logic, leveraging compiler checks to prevent broken interactions between different product functionalities.