Cloudflare Workers ra mắt tính năng phân quyền chi tiết cho đội ngũ và AI agents

Khi ngày càng có nhiều đội ngũ — và giờ đây là các tác nhân (agent) — xây dựng ứng dụng trên Nền tảng Nhà phát triển (Developer Platform) của Cloudflare, việc thiết lập các quyền kiểm soát truy cập phù hợp là vô cùng quan trọng để giúp bạn triển khai ứng dụng một cách an toàn. Suy cho cùng, điều cuối cùng bạn muốn là một agent thực hiện thay đổi trong môi trường production chỉ vì nó được cấp quyền truy cập nhiều hơn mức cần thiết.

Giờ đây, bạn có thể cấp quyền truy cập cho một đồng nghiệp hoặc một agent vào một Worker cụ thể, để họ chỉ có thể thực hiện thay đổi đối với ứng dụng đó mà không ảnh hưởng đến các tài nguyên khác trong tài khoản của bạn. Hơn nữa, chúng tôi cung cấp bốn vai trò mới để bạn có thể giới hạn chính xác những gì họ có thể làm:

Vai trò

Những gì bạn có thể thực hiện

Khi nào nên sử dụng

Metadata Read-Only (Chỉ đọc siêu dữ liệu)

Xem danh sách tài nguyên, cài đặt và dữ liệu quan sát được (observability data) như số liệu, nhật ký (logs) và dấu vết (traces) mà không có quyền truy cập vào nội dung sản phẩm.

Khi bạn muốn cấp quyền truy cập vào dữ liệu quan sát cho thành viên trong nhóm hoặc agent để họ gỡ lỗi (debug) các vấn đề, nhưng không muốn họ truy cập vào mã nguồn của bạn.

Content Read-Only (Chỉ đọc nội dung)

Đọc nội dung sản phẩm, chẳng hạn như mã Worker hoặc nội dung cơ sở dữ liệu D1, mà không có khả năng sửa đổi chúng.

Khi bạn muốn cấp quyền truy cập vào mã nguồn cho thành viên trong nhóm hoặc agent, nhưng không muốn họ có thể thực hiện bất kỳ thay đổi nào đối với Worker của bạn.

Editor (Người chỉnh sửa)

Đọc và ghi nội dung sản phẩm, cập nhật cài đặt. Không thể tạo, xóa hoặc đổi tên tài nguyên.

Khi bạn muốn cấp quyền triển khai thay đổi cho Worker cho thành viên trong nhóm, agent hoặc hệ thống CI/CD của bạn, nhưng muốn ngăn họ xóa Worker đó.

Admin (Quản trị viên)

Toàn quyền kiểm soát tài nguyên, bao gồm tạo, đổi tên, xóa và cấp quyền cho người dùng khác.

Khi bạn muốn cấp toàn quyền truy cập vào Worker cho thành viên trong nhóm hoặc agent, bao gồm cả quyền xóa Worker đó, nhưng không muốn cấp quyền truy cập vào bất kỳ Worker hoặc tài nguyên nào khác trong tài khoản của bạn.

Các vai trò mới hiện đã khả dụng cho tất cả khách hàng. Bạn có thể gán chúng cho một người dùng cụ thể, để khi họ đăng nhập vào bảng điều khiển, họ sẽ chỉ thấy Worker mà bạn đã cấp quyền. Hoặc, bạn có thể tạo một API token với quyền truy cập theo phạm vi (scoped access) và cung cấp cho agent của mình để đảm bảo chúng chỉ có quyền truy cập vào đúng ứng dụng đó.

Dưới đây là ví dụ về cách tạo API token với các quyền hạn theo từng Worker:

Các vai trò được thiết kế phù hợp với cách các đội ngũ xây dựng ứng dụng

Khi xác định các vai trò này, chúng tôi muốn đạt được sự cân bằng hợp lý. Các vai trò quá rộng buộc bạn phải cấp quyền nhiều hơn dự định, làm suy yếu nguyên tắc đặc quyền tối thiểu (principle of least privilege), trong khi việc cung cấp quá nhiều quyền riêng lẻ lại gây khó khăn trong việc xác định nên cấp quyền nào. Chúng tôi đã chốt lại bốn vai trò phản ánh các cấp độ truy cập mà bạn có thể muốn cấp cho một người hoặc một agent: đủ để gỡ lỗi tài nguyên mà không làm lộ nội dung, đọc nội dung mà không thay đổi nó, thực hiện thay đổi mà không thể xóa tài nguyên, hoặc quản lý toàn bộ tài nguyên đó.

Chúng tôi dự định sử dụng các vai trò tương tự khi triển khai các quyền kiểm soát truy cập ở cấp độ tài nguyên cho các sản phẩm khác trên Nền tảng Nhà phát triển, bao gồm D1, R2 và KV. Mỗi vai trò có thể được áp dụng tại một trong ba phạm vi. Ví dụ: nếu bạn thiết lập quyền kiểm soát “metadata read-only”, đây là cách nó hiển thị ở các cấp độ khác nhau:

Vai trò và phạm vi xác định những gì một người có thể làm và họ có thể thực hiện trên những tài nguyên nào. Hãy cùng xem cách thức này hoạt động trong một số quy trình làm việc phổ biến với Workers.

Gỡ lỗi mà không làm lộ mã nguồn

Để gỡ lỗi một vấn đề, kỹ sư hoặc agent có thể cần xem cài đặt, số liệu, nhật ký và dấu vết của Worker để hiểu điều gì đã xảy ra. Nhưng họ không cần phải xem mã của Worker hoặc thực hiện thay đổi đối với nó.

Metadata Read-Only cung cấp cho họ quyền truy cập vào thông tin đó mà không làm lộ mã nguồn của Worker. Họ có thể truy vấn dữ liệu phân tích thông qua GraphQL API, truy cập nhật ký, kiểm tra dấu vết và các dữ liệu quan sát khác. Các yêu cầu đó chỉ trả về dữ liệu cho các Worker mà họ có quyền truy cập. Nếu một agent được giới hạn trong một Worker, nó có thể sử dụng các API của Cloudflare để điều tra vấn đề mà không thấy dữ liệu từ bất kỳ Worker nào khác trong tài khoản.

Khi chúng tôi đưa các vai trò này vào nhiều sản phẩm Nền tảng Nhà phát triển hơn, chúng tôi dự định duy trì sự phân tách đó. Một người có thể kiểm tra cài đặt và dữ liệu quan sát cho cơ sở dữ liệu D1 hoặc bucket R2 mà không thể đọc các giá trị trong cơ sở dữ liệu hoặc các tệp trong bucket đó.

Xem xét mã nguồn mà không thay đổi nó

Một đồng nghiệp hoặc agent kiểm duyệt mã nguồn có thể cần đọc mã đang chạy trong Worker để hiểu cách nó hoạt động, điều tra lỗi hoặc xem xét một thay đổi được đề xuất. Nhưng điều đó không có nghĩa là họ nên có quyền triển khai mã mới hoặc cập nhật cài đặt của Worker.

Content Read-Only cung cấp sự phân tách đó. Nó cho phép họ truy xuất và xem xét mã của Worker mà không thể sửa đổi hoặc triển khai nó. Khi được giới hạn trong một Worker riêng lẻ, họ chỉ có thể đọc mã của Worker đó thay vì mã của tất cả Worker trong tài khoản.

Sau khi được hỗ trợ cho các sản phẩm Nền tảng Nhà phát triển khác, Content Read-Only sẽ hoạt động theo cách tương tự: một người có thể đọc dữ liệu được lưu trữ trong cơ sở dữ liệu D1, KV namespace hoặc R2 bucket mà không thể sửa đổi chúng.

Cho phép CI triển khai mà không cần cấp toàn quyền kiểm soát

Quy trình CI/CD chỉ cần quyền truy cập vào ứng dụng mà nó triển khai. Nó không nên có khả năng thay đổi một Worker khác hoặc xóa chính Worker của mình và làm gián đoạn ứng dụng.

Với các quyền kiểm soát truy cập ở cấp độ Worker, mỗi quy trình làm việc có thể có API token riêng với vai trò Editor, được giới hạn trong một Worker. Nếu quy trình làm việc bị cấu hình sai hoặc token bị lộ, tác động vẫn được kiểm soát: nó có thể triển khai các thay đổi cho Worker đó, nhưng không thể xóa nó hoặc can thiệp vào bất kỳ ứng dụng nào khác trong tài khoản của bạn.

Xóa một Worker với quyền Admin

Admin là cấp độ truy cập cao nhất mà bạn có thể cấp. Nó cho phép bạn xóa một ứng dụng. Bạn vẫn có thể giới hạn vai trò này cho một Worker riêng lẻ để quyền truy cập không mở rộng ra mọi Worker trong tài khoản.

Routes & Custom Domains (Các tuyến đường & Tên miền tùy chỉnh)

Bạn có thể thêm các route hoặc Custom Domain vào một Worker để chỉ định hostname nào được định tuyến đến ứng dụng đó. Ví dụ: cấu hình này trong tệp Wrangler của bạn sẽ gửi lưu lượng truy cập cho example.com đến Worker:

Vì việc thay đổi route đó có thể chuyển hướng lưu lượng truy cập production hoặc làm gián đoạn ứng dụng, nên chỉ quyền truy cập vào Worker là chưa đủ. Để thêm, thay đổi hoặc xóa một route hoặc Custom Domain, bạn cần cả quyền Editor đối với Worker đó và quyền Workers Routes cho zone tương ứng.