Du schreibst eine Rego-Richtlinie, führst OPA Test dagegen aus, beobachtest, wie alle Fälle grün werden, und für einen Moment fühlst du dich fertig. Genau an diesem Punkt wird es spannend.
Newton erlaubt Entwicklern, Autorisierungsrichtlinien in Rego zu schreiben – derselben Richtliniensprache, die viele Unternehmens-Compliance-Teams bereits außerhalb von Krypto verwenden. Das ist hier ehrlich gesagt eine sinnvolle Entscheidung. Diese Richtlinien werden von einer in Rust basierten Engine ausgewertet, die von Microsofts Regorus-Projekt abgezweigt wurde und mit Newtons eigenen Built-ins für Krypto, Identität, Datenschutz und Zeitprüfungen erweitert wurde. Newtons eigener CLI liefert sogar einen nicht-strengen Flag mit, speziell damit der lokale Regorus-Befehl sich in einer OPA-kompatiblen Weise verhält – eine leise Anerkennung, dass das Standardverhalten das nicht tut. Und Newtons eigener Testleitfaden sagt dir als ersten Schritt, deine Rego-Richtlinie mit OPA Test, der eigentlichen Referenzimplementierung, unit-zu-testen, bevor irgendetwas Newton-spezifisches jemals die Richtlinie berührt.
Regorus ist, nach dem, was die eigenen Maintainer sagen, größtenteils kompatibel mit OPA, aber nicht vollständig. Es besteht die echte OPA-Conformance-Suite für die meisten Builtins, aber nicht für alle. Und Newtons eigene Dokumentation listet ganze Kategorien in seinem Build als noch nicht unterstützt: Standard-Kryptohashing- und HMAC-Funktionen, JWT-Codierung und -Verifikation, http.send, net.*, json.patch, graphql, AWS-Provider-Builtins sowie die eigene Metadaten-Introspektion von Rego. Newton weist dich stattdessen auf seine eigenen Erweiterungen hin. Nichts davon ist irgendein obskurer Edge-Case. crypto.hmac.equal zum Beispiel ist der lehrbuchmäßig zeitkonstante Weg, zwei MACs in Rego zu vergleichen – ganz schlicht auf der eigenen OPA-Seite dokumentiert.
Es lohnt sich, es klar zu sagen: Ein Teil dieser Lücke ist bewusst, nicht bloß Zeitverzug. Regorus schließt kryptografische Builtins per Design aus – entwickelt für Szenarien für vertrauliches Computing, in denen man die Kontrolle darüber, was in der Trusted-Computing-Base steckt, besonders eng halten will. Das ist ein echtes Sicherheitsargument, keine Trägheit. Es ändert nur nicht, was passiert, wenn jemand nach dieser Funktion greift, ohne zu wissen, in welche Kategorie er damit fällt.
Stell dir die Sequenz vor: Ein Policy-Autor muss bestätigen, dass die Oracle-Payload nicht manipuliert wurde, greift zu crypto.hmac.equal, weil dahin jeder RegO-Verweis zeigt, schreibt eine companion policy_test.rego, führt opa test aus, sieht, dass es durchläuft – denn opa test ist wörtlich die Referenzimplementierung, die sich selbst gegen ihre eigenen Semantiken prüft. In diesem Schritt wird keinerlei „Newton-Engine“ berührt. Die Policy wirkt fertig. Erst wenn sie bereitgestellt und von Newtons eigenem Regorus-Build evaluiert wird, schlägt genau dieser Aufruf fehl, weil dieser spezielle Builtin nie in den Fork gelangt ist. Und das hier ist der Teil, zu dem ich immer wieder zurückkomme: Je „lehrbuchkorrekter“ dein Rego ist, desto stärker bist du exponiert – weil es präzise die standardisierten, gut dokumentierten Builtins sind, zu denen Newton noch nicht vorgedrungen ist, nicht die Newton-spezifischen, die offensichtlich funktionieren. Wer hätte gedacht, dass der Griff zur standardmäßigeren Funktion die riskantere Bewegung ist.
Das ist, glaube ich, wirklich ein Supply-Chain-Problem, nur als Testproblem verkleidet. OPA ist die Original-Spezifikation und die Ground Truth, geschrieben in Go. Regorus ist eine Rust-Neuimplementierung dieser Spezifikation, verifiziert gegen OPA-eigene Conformance-Suite, aber – so die eigene Aussage – unvollständig; gebaut und gepflegt von Microsoft. Newton forkt Regorus wiederum darauf und schichtet seine eigenen Builtins oben drauf. Und ehrlich gesagt dürfte die Lücke eher Newtons eigene Roadmap-Logik folgen als irgendeiner Unachtsamkeit: Das Ausliefern von Identitäts- und Privacy-Builtins, die kein anderer Rego-Runtime hat, ist eine differenzierende Arbeit, die sich zu finanzieren lohnt. Vollständige Parität bei generischen Builtins zu jagen, die noch keine Priorität haben, ist dagegen die unglamouröse Sorte, die wartet. Jeder Hop entlang dieser Kette kann still und leise einen Streifen der Garantie verlieren, den die darüberliegende Schicht zuvor gegeben hat – und der Entwickler, der eine einzelne Rego-Datei schreibt, hat nur direkte Sicht auf die erste Verbindungsstelle, das eine mit dem öffentlichen Playground und der vertrauten CLI.
Die Lücke ist übrigens nicht wirklich versteckt. Sie wird, Funktion für Funktion, in Newtons eigenem Rego-Syntax-Guide katalogisiert – mit einer alternativen Benennung für nahezu jede fehlende Kategorie. Aber ein Katalog auf einer Referenzseite und eine Warnung in dem Tool, das du ohnehin schon offen hast, sind zwei verschiedene Dinge. Newtons vollständiger empfohlener Workflow geht über opa test allein hinaus: bis hin zu einem newt_simulatePolicy-Call, der die komplette Policy gegen echte Newton-Netzwerkbedingungen laufen lässt, bevor irgendetwas deployed wird – und dieser Schritt würde genau so einen Fehler abfangen. Die ehrliche Version lautet also nicht, dass die Information nicht existiert. Sie lautet, dass der schnellste, reflexartigste Schritt im Prozess genau derjenige ist, der die Ebene nicht sehen kann, in der das eigentliche Scheitern lebt.
Und dennoch: Anerkennung, wo sie hingehört. Eine Rust-Neuimplementierung von Rego so hinzubekommen, dass sie OPA-eigene Conformance-Suite über mehrere Sprachbindungen hinweg besteht – ohne dabei eine Go-Runtime mitzuschleppen – ist eine wirklich seltene Ingenieursleistung mit konsequenter Umsetzung, keine hastig nebenbei gemachte Sache. Und Newton hat die Lücke auch nicht irgendwo so versteckt, dass man sie leicht übersieht: Es hat aufgeschrieben, was fehlt und was stattdessen zu verwenden ist – Kategorie für Kategorie. Eine existierende, gut verstandene Policy-Sprache wiederzuverwenden statt etwas Eigenes und Proprietäres zu erfinden, ist für Entwickler außerdem, ehrlich gesagt, die großzügigere Entscheidung – selbst wenn die Compliance-Lücke genau darin steckt.
Vielleicht ist es einfach nur vernünftig, eine zweckgebundene Erweiterungsschicht auf eine ohnehin teilweise Neuimplementierung des Specs von jemand anderem zu stapeln, um ein bestimmtes Feature schnell auszuliefern. Oder vielleicht ist es genau der Schachzug, der Tests gegen OPA – bevor du aus einem Sicherheitsschritt heraus deployst – still und leise in einen unvollständigen Schritt verwandelt, ohne dass die Person, die die Policy schreibt, je herausfindet, welche Stelle genau scheitert.