Cloudflare Workers hiện hỗ trợ Access Policies trực tiếp — Khóa các ứng dụng nội bộ theo mặc định
Cloudflare giờ cho phép bạn gắn Access policies trực tiếp vào Workers, để mọi domain và preview URL đều nằm sau đăng nhập công ty theo mặc định. Các mặc định ở cấp tài khoản khiến private-by-default trở thành chuẩn mực, và API ctx.access mới loại bỏ boilerplate JWT.

Cloudflare đã phát hành một nâng cấp đáng kể cho Workers: bạn giờ có thể áp dụng Cloudflare Access trực tiếp vào một Worker, hoặc vào mọi Worker trong tài khoản của bạn, để các ứng dụng nội bộ nằm sau đăng nhập công ty theo mặc định. Không còn phụ thuộc vào việc mỗi developer nhớ khóa các deployment của riêng họ.
Trước đây, Access policies được gắn với hostname. Nếu bạn có một Worker truy cập được trên nhiều domain, bạn phải cấu hình Access trên từng domain một. Bỏ sót một domain, và domain đó sẽ bị lộ. Giờ đây, policy gắn vào chính Worker, bao phủ mọi domain liên quan — custom domains, routes, workers.dev subdomains, và preview URLs.
Bạn có ba cấp độ kiểm soát:
- Account-level policy: Đặt một lần, và mọi Worker trong tài khoản — hiện tại và tương lai — đều private theo mặc định. Bạn có thể giới hạn nó chỉ cho preview URLs, lưu lượng production, hoặc cả hai.
- Worker-level policy: Khóa một Worker cụ thể mà không ảnh hưởng đến phần còn lại của tài khoản.
- Bypass: Nếu bạn có một Worker nên public, bạn có thể ghi đè policy cấp tài khoản trên Worker cụ thể đó.
Đối với các đội chạy nền tảng nội bộ, có một mẹo hay: đặt một Access policy trên dispatch Worker của bạn trong Workers for Platforms, và mọi Worker được triển khai qua nó sẽ private theo mặc định. Cloudflare cũng open-source một internal sites template minh họa mẫu này.
Danh tính trong code của bạn mà không đau đầu với JWT
Khi Access bảo vệ một Worker, bạn có thể lấy email, tên, và nhóm của người dùng đã xác thực trực tiếp trong code qua đối tượng ctx. Không còn phải parse JWT, xác minh chữ ký, và trích xuất claims.
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}`);
}
};Đối với phát triển cục bộ, bạn có thể mô phỏng một người dùng đã xác thực trong wrangler.jsonc:
{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "admin@company.com" }
}
}
}Điều này có nghĩa bạn có thể kiểm tra hành vi theo từng người dùng mà không cần deploy và trải qua toàn bộ luồng đăng nhập Access mỗi lần.
Bên dưới: FL2 làm cho điều này khả thi
Tính năng này được xây dựng trên FL2, proxy mô-đun dựa trên Rust của Cloudflare. Để gắn Access vào Workers thay vì hostname, Cloudflare phải tách routing của Workers khỏi execution của Workers, chuyển logic routing để chạy trước Access. Trong hệ thống cũ dựa trên NGINX/Lua FL1, việc refactor đó sẽ rủi ro. Hệ thống mô-đun nghiêm ngặt của FL2 với các pha khai báo tĩnh làm cho nó an toàn, để compiler bắt các tương tác hỏng.
Đặt một Access policy trên dispatch Worker của bạn, và mọi Worker được triển khai qua nó sẽ private theo mặc định.
Thảo luận
0 bình luận
Hãy là người đầu tiên thảo luận.