ви пишете rego політику, запускаєте opa test проти неї, стежите, як кожен кейс стає зеленим, і на мить відчуваєте, ніби все зроблено. Саме в цей момент стає по-справжньому цікаво.
newton дозволяє розробникам писати політики авторизації мовою rego — тією самою мовою політик, яку вже використовують багато команд із корпоративної відповідності поза межами крипто. Чесно кажучи, це тут цілком розумний вибір. Ці політики обробляє рушій на базі rust, який є форком regorus проєкту від microsoft, розширеним власними вбудованими функціями newton для перевірок крипто, ідентичності, приватності та часу. Навіть власний cli newton постачається з прапорцем non strict спеціально для того, щоб локальна команда regorus могла поводитися так, щоб бути сумісною з opa — це тихе визнання того, що поведінка за замовчуванням не є такою. І власний гайд з тестування newton каже вам, як найперший крок, юніт-тестувати вашу rego політику за допомогою opa test — власне референсної реалізації — перш ніж що-небудь специфічне для newton взагалі торкнеться політики.
regorus, судячи з того, що кажуть його власні мейнтейнері, здебільшого сумісний з opa, але не повністю. він проходить реальний набір тестів конформності opa для більшості вбудованих примітивів, але не для всіх. а в документації ньютона вказано цілі категорії, які ще не підтримуються в його збірці: стандартні функції хешування та hmac для крипто; кодування і верифікація jwt; http.send; net.*; json.patch; graphql; вбудовані примітиви провайдера aws; інтроспекція метаданих самої rego. ньютона спрямовує вас до власних розширень замість цього. і жодне з того, чого немає, не є якоюсь прихованою рідкісною крайністю. crypto.hmac.equal, наприклад, — це підручниковий безпечний за часом спосіб порівняти два mac у rego, прямо задокументований на власному сайті opa.
варто сказати прямо: частина цієї прогалини зроблена навмисно, а не через відставання. regorus виключає криптографічні вбудовані примітиви за задумом — для середовищ конфіденційних обчислень, де хочуть жорстко контролювати вміст того, що входить у trusted computing base. це справжня аргументація з точки зору безпеки, а не лінощі. просто це не змінює того, що стається з тим, хто звертається до цієї функції, не знаючи, до якої категорії вона належить.
уявіть послідовність. автор політики має підтвердити, що oracle-пейлоад не було підмінено, тягнеться до crypto.hmac.equal, бо саме туди вказує будь-яке референсне opa. пише супутню policy_test.rego, запускає opa test, бачить, що воно проходить, бо opa test — це буквально референсна реалізація, яка перевіряє себе на відповідність власній семантиці. нічого з цього кроку не торкається движка ньютона. політика виглядає готовою. і лише коли її розгортають та оцінюють у regorus-збірці ньютона, той самий виклик не вдається розв’язати, бо цей конкретний вбудований примітив ніколи не потрапив у форк. і ось та частина, до якої я весь час повертаюся: що більш «підручниково правильною» є ваша rego, то більш ви наражаєтеся, адже ризик тут у точності з типовими, добре задокументованими вбудованими функціями, яких ньютона ще не дотягнув, а не в ньютона-специфічних, які, очевидно, працюють. хто б міг подумати, що звернення до більш стандартної функції — ризикованіший крок.
тобто, я думаю, це насправді проблема ланцюга постачання, замаскована під проблему тестування. opa — це оригінальна специфікація і джерело істини, написане на go. regorus — це rust-відтворення цієї специфікації, перевірене на власному наборі конформності opa, але за власним же визнанням неповне; його зібрано і підтримує microsoft. ньютона знову форкнув regorus поверх цього та нашарував свої власні вбудовані примітиви. і чесно кажучи, прогалина, ймовірно, відстежує логіку roadmap ньютона більше, ніж будь-яку неуважність: релізити вбудовані примітиви ідентичності та приватності, яких немає в жодному іншому runtime для rego, — це диференційована робота, варта фінансування, тоді як гонитва за повною парністю в загальних вбудованих примітивах, які ще не пріоритет, — це буденний тип роботи, що чекає. кожен перехід униз цього ланцюжка може тихо прибрати шматок гарантії, яку забезпечив шар вище, а розробник, який пише один файл rego, має прямий огляд лише першої ланки — тієї, що має публічний майданчик і знайомий cli.
прогалина насправді не прихована, якщо бути чесним. вона каталогізована, функція за функцією, у власному гайді з синтаксису rego від ньютона, і для майже кожної відсутньої категорії є альтернативна назва. але каталог на сторінці довідки та попередження в інструменті, який у вас уже відкритий, — це різні речі. повний рекомендований workflow ньютона йде далі, ніж лише opa test: аж до виклику newt_simulatePolicy, який проганяє всю політику через реальні мережеві умови ньютона перед будь-яким розгортанням, і цей крок упіймав би саме таке. тож чесна версія не в тому, що інформації немає. чесна версія в тому, що найшвидший, найбільш рефлекторний крок у процесі — це якраз той, який не здатен побачити шар, де живе реальна помилка.
віддам належне, але. зробити rust-відтворення rego, щоб воно проходило власний набір конформності opa, на пів дюжини мовних зв’язок, не тягнучи за собою go runtime — це справді рідкісна робота з інженерним доведенням до кінця, а не поспішний побічний проєкт. і ньютона не сховав прогалину десь у зручному місці, яке легко не помітити: він записав, що саме відсутнє, і що слід використовувати натомість, категорія за категорією. повторне використання вже існуючої, добре зрозумілої мови політик замість винайдення чогось власницького — чесно кажучи, також більш щедрий вибір для розробників, навіть із наявною прогалиною в комплаєнсі всередині.
можливо, накладання спеціально створеного шару розширень поверх уже частково відтвореної специфікації стороннього проєкту — це просто розумний спосіб швидко доправити конкретну фічу. або, можливо, це саме той крок, який тихо перетворює тестування на opa ще до розгортання з безпекового кроку на неповний, без того щоб людина, яка пише політику, взагалі дізналася, що саме.