вы пишете политику Rego, запускаете opa test против неё, следите, как все кейсы становятся зелёными, и на секунду ощущаете, что всё сделано. Именно в этот момент становится по-настоящему интересно.
Newton позволяет разработчикам писать политики авторизации на Rego — том же языке политик, который множество команд по комплаенсу на предприятиях уже используют вне криптосферы. И, честно говоря, это здесь вполне разумный выбор. Эти политики оцениваются форком на базе движка на Rust, ответвлённым от проекта Microsoft Regorus, расширенным собственными builtins от Newton для проверок крипто, идентичности, приватности и времени. Собственная CLI Newton даже поставляется с нестрогим флагом, специально чтобы локальная команда regorus могла вести себя совместимо с OPA; это тихое признание того, что поведение по умолчанию — не совсем то. А ещё руководство по тестированию Newton говорит вам, как самый первый шаг, — unit-тестировать ваш Rego с помощью opa test, то есть реальной эталонной реализации, прежде чем вообще что-либо специфичное для Newton начнёт касаться политики.
regorus, судя по тому, что говорят его собственные мейнтейнеры, в основном соответствует opa, но не полностью. он проходит реальный набор тестов на соответствие (conformance suite) opa для большинства builtins, но не для всех, а в документации Ньютона прямо перечислены целые категории, которые ещё не поддержаны в его сборке: стандартные функции криптографического хеширования и hmac, кодирование и верификация jwt, http.send, net.*, json.patch, graphql, builtins провайдера aws, а также introspection метаданных самого Rego. Ньютона направляет вас на его собственные расширения. и в том, что отсутствует, нет ничего вроде какого-то редкого «краевого случая». crypto.hmac.equal, например, — это учебник-эталонный (textbook) способ безопасно сравнивать два MAC в Rego по времени (timing safe), причём в документации на сайте opa это прямо описано.
стоит сказать прямо: часть этого разрыва сделана намеренно, а не связана с отставанием. regorus исключает криптографические builtins по замыслу — для сценариев конфиденциальных вычислений (confidential computing), где важен жёсткий контроль того, что входит в доверенную вычислительную базу. это реальная причина с точки зрения безопасности, а не лень. просто это не меняет того, что произойдёт с тем, кто вызывает эту функцию, не зная, к какой категории она относится.
представьте себе последовательность. автор политики должен убедиться, что полезная нагрузка оракула не была изменена (tampered with), обращается к crypto.hmac.equal, потому что именно на это указывает любой справочник по Rego. он пишет companion policy_test.rego, запускает opa test, смотрит, как тест проходит, потому что opa test — это буквально эталонная реализация, проверяющая саму себя на соответствие собственной семантике. на этом шаге вообще не происходит вызов движка Ньютона. политика выглядит готовой. и только после того, как она будет развернута и выполнена сборкой regorus от Ньютона, тот же вызов перестаёт разрешаться: потому что этот конкретный встроенный (builtin) не попал в форк. и вот о чём я постоянно возвращаюсь: чем «более учебно правильно» (textbook correct) написан ваш Rego, тем вы более уязвимы — ведь именно стандартные, хорошо задокументированные builtins, которые у Ньютона ещё не готовы, создают риск, а не «ньютоно-специфичные», которые, очевидно, работают. кто бы мог подумать, что обращение к более стандартной функции — более рискованный шаг.
на мой взгляд, это действительно проблема цепочки поставок, замаскированная под проблему тестирования. opa — это исходная спецификация и единственный источник истины, написанный на go. regorus — это rust-реализация этой спецификации, проверенная на conformance suite opa, но по собственному признанию — неполная; она собрана и поддерживается Microsoft. дальше Ньютон форкает regorus и поверх накладывает свои builtins. и честно, разрыв, вероятно, отражает дорожную карту Ньютона больше, чем какую-то небрежность: выпуск identity и privacy builtins, которых нет в других рантаймах Rego, — это дифференцирующая работа, достойная финансирования, тогда как погоня за полным паритетом по «общим» builtins, которые пока не приоритет, — это скучный и отложенный в ожидание шаг. каждый переход по этой цепочке может незаметно отщипнуть частичку гарантии, которую давал уровень выше, а у разработчика, который пишет один файл Rego, есть прямой вид только на первое звено — то, у которого есть публичная песочница и привычная CLI.
разрыв, справедливости ради, не скрыт. он каталогизирован — функция за функцией — в собственном гайде Ньютона по синтаксису Rego, и для почти каждой отсутствующей категории есть альтернативное название. но каталог в справочной странице и предупреждение внутри инструмента, который у вас уже открыт, — это разные вещи. полный рекомендованный Ньютона процесс всё-таки идёт дальше, чем один opa test: до вызова newt_simulatePolicy, который прогоняет всю политику по реальным сетевым условиям Ньютона до развертывания, и этот шаг как раз поймает ровно такую проблему. так что честная версия не в том, что информация не существует — а в том, что самый быстрый и самый рефлекторный шаг в процессе как раз тот, который не может увидеть слой, где находится реальное падение.
заслуживает отдельного признания, тем не менее. довести rust-реализацию Rego до прохождения собственного conformance suite opa, причём сразу на нескольких языковых биндингах, не таща при этом go runtime — это действительно редкий пример инженерного доведения до конца, а не поспешный сайд-проект. и Ньютона не спрятал разрыв где-то «удобно пропустить»: он записал, что именно отсутствует и что использовать вместо этого, категория за категорией. повторное использование уже существующего, хорошо понятного языка политик вместо изобретения чего-то проприетарного — это тоже, по-честному, более щедрый выбор для разработчиков, даже при том что разрыв соответствия (compliance gap) присутствует внутри.
может быть, наслаивание специально созданного слоя расширений поверх уже частичной пере-реализации чужой спецификации — это просто разумный способ быстро выпустить нужную функцию. или, возможно, это и есть тот самый точный шаг, который незаметно переводит тестирование на opa перед развертыванием из «безопасного этапа» в неполный, а человек, пишущий политику, так и не узнаёт, где именно проходит граница реальной проблемы.