bạn viết một chính sách rego, chạy opa test cho nó, theo dõi xem mọi trường hợp đều chuyển sang xanh, và trong một giây bạn cảm thấy như đã xong. Cảm giác đó chính là chỗ mọi thứ trở nên thú vị.
newton cho phép các nhà phát triển viết các chính sách ủy quyền bằng rego—ngôn ngữ chính sách mà nhiều nhóm tuân thủ doanh nghiệp đã sử dụng ngoài lĩnh vực crypto. Nói thật thì đây là một lựa chọn khá hợp lý trong bối cảnh này. Các chính sách đó được đánh giá bởi một engine chạy trên rust, được fork từ dự án regorus của microsoft, và được mở rộng với các builtins riêng của newton cho các kiểm tra crypto, identity, privacy và time. CLI riêng của newton thậm chí còn có kèm một cờ non strict (không nghiêm ngặt) chỉ để lệnh regorus cục bộ của họ có thể hoạt động theo cách tương thích với opa—một sự thừa nhận thầm lặng rằng hành vi mặc định không phải vậy. Và hướng dẫn kiểm thử riêng của newton nói với bạn rằng, như bước đầu tiên ngay từ đầu, hãy unit test chính sách rego của bạn bằng opa test—chính là bản triển khai tham chiếu—trước khi bất kỳ thứ gì mang tính đặc thù của newton thực sự chạm vào chính sách.
regorus, theo những gì các maintainer của nó nói, nhìn chung là tuân thủ với opa ở mức “phần lớn”, không phải “toàn bộ”. nó vượt qua bộ kiểm thử conformance thật của opa cho hầu hết các builtins, nhưng không phải tất cả, và tài liệu của newton liệt kê cả những nhóm đầy đủ là chưa được hỗ trợ trong build của nó: các hàm băm crypto chuẩn và hmac, mã hóa/xác thực jwt, http.send, net.*, json.patch, graphql, các builtins của aws provider, phần introspection metadata của chính rego. newton hướng bạn sang các phần mở rộng riêng của nó. không có gì trong chỗ thiếu này là một “case biên” hiếm hoi. ví dụ crypto.hmac.equal: đó là cách so sánh hai mac theo kiểu timing-safe trong rego đúng kiểu sách vở, được tài liệu công khai ngay trên site của opa.
nên nói thẳng ra: phần “khoảng trống” đó không hẳn do chậm trễ; một phần là cố ý. regorus loại trừ các builtins mã hóa theo thiết kế, dành cho các thiết lập tính toán tin cậy cần kiểm soát chặt thứ gì được đưa vào “trusted computing base”. đó là một lý do bảo mật thật sự, không phải do lười. nó chỉ không làm thay đổi điều xảy ra với bất kỳ ai gọi hàm đó mà không biết họ đang rơi vào đúng “nhóm” nào.
nói thế này cho dễ hình dung chuỗi thao tác: một tác giả chính sách cần xác nhận rằng payload của oracle không bị can thiệp, nên tìm đến crypto.hmac.equal vì đó là thứ mà bất kỳ tham chiếu rego nào cũng sẽ dẫn bạn tới, rồi viết một chính sách đồng hành policy_test.rego, chạy opa test, và xem nó pass. bởi vì opa test thực ra chính là bản tham chiếu: tự kiểm tra mình dựa trên ngữ nghĩa của chính nó. bước đó hoàn toàn không đụng gì đến “engine” của newton cả. chính sách trông như đã xong. chỉ khi nó được triển khai và được newton tự biên dịch/đánh giá bằng bản build regorus của nó thì lệnh gọi tương tự mới fail do không resolve được, vì built-in cụ thể đó chưa hề có trong nhánh (fork). và đây là phần mình cứ quay lại mãi: rego của bạn càng đúng theo kiểu sách vở chuẩn mực thì bạn càng bị lộ, vì chính xác những builtins chuẩn, được tài liệu rõ ràng mà newton chưa kịp hỗ trợ—không phải các builtins đặc thù của newton (hiển nhiên là chạy được). ai lại nghĩ rằng việc dùng hàm “chuẩn” hơn thì lại là nước đi rủi ro hơn?
theo mình thì đó thực sự là một vấn đề chuỗi cung ứng được khoác lên như một vấn đề kiểm thử. opa là đặc tả gốc và là “sự thật” (ground truth), viết bằng go. regorus là một bản reimplementation bằng rust của đặc tả đó, được xác minh theo bộ conformance của chính opa nhưng theo lời của nó thì là chưa hoàn chỉnh, được xây dựng và duy trì bởi microsoft. rồi newton lại fork regorus một lần nữa và chồng thêm các builtins riêng của mình lên trên. và thành thật mà nói, khoảng trống có lẽ phản ánh logic roadmap của newton nhiều hơn là sự cẩu thả: những builtins về danh tính và quyền riêng tư—mà không runtime rego nào khác có—là phần việc đáng được tài trợ; còn việc chạy đuổi cho đủ “parity” đối với các builtins phổ dụng mà chưa được ưu tiên thì lại là thứ nhàm chán phải chờ. mỗi lần nhảy qua một lớp trong chuỗi đó có thể âm thầm làm rơi đi một lát “bảo đảm” mà lớp phía trên đã tạo ra, và người viết một file rego chỉ có tầm nhìn trực tiếp vào liên kết đầu tiên—liên kết có playground công khai và cli quen thuộc.
phải công bằng mà nói: phần “khoảng trống” đó không hề bị giấu. nó được liệt kê rõ ràng, từng hàm một, trong hướng dẫn cú pháp rego của newton, kèm tên một phương án thay thế cho gần như mọi nhóm còn thiếu. nhưng một bản mục lục trên trang tham chiếu và một cảnh báo ngay trong công cụ mà bạn đang mở—đó là hai chuyện khác nhau. quy trình khuyến nghị đầy đủ của newton còn đi xa hơn opa test: cho đến một lời gọi newt_simulatePolicy, chạy toàn bộ chính sách qua các điều kiện mạng newton thực tế trước khi triển khai. bước đó đáng lẽ sẽ bắt đúng lỗi kiểu này. vì vậy bản “thành thật” không phải là thông tin không tồn tại. mà là: bước nhanh nhất, phản xạ nhất trong quy trình—chính bước đó—lại không thể nhìn thấy lớp nơi thất bại thực sự nằm.
ghi nhận công sức đúng chỗ, dù sao. việc đưa một bản reimplementation bằng rust của rego đi qua bộ conformance của chính opa, trên nửa tá ngôn ngữ ràng buộc (language bindings), mà không kéo thêm một runtime go theo cùng, là một mảnh kỹ thuật hiếm có, không phải dự án nhánh làm vội. và newton cũng không “chôn” khoảng trống ở đâu tiện để bỏ sót: nó ghi ra cái gì còn thiếu và nên dùng gì thay thế, theo từng hạng mục. dùng lại một ngôn ngữ chính sách đã được hiểu rõ sẵn thay vì tự phát minh thứ gì đó độc quyền cũng, thật lòng, là lựa chọn “dễ dãi” hơn cho nhà phát triển—dù vẫn có khoảng hở tuân thủ nằm ngay trong chính thứ đó.
có thể việc xếp một lớp extension được thiết kế riêng lên trên một bản reimplementation còn thiếu của đặc tả nào đó của người khác chỉ là cách hợp lý để triển khai một tính năng cụ thể nhanh. hoặc có thể đó chính là nước đi làm cho bạn—một cách âm thầm—chuyển từ bước kiểm thử trên opa trước khi triển khai (một bước an toàn) sang trạng thái kiểm thử không hoàn chỉnh, mà người viết chính sách thậm chí không bao giờ biết mình đang thiếu chỗ nào.