vous écrivez une politique rego, lancez opa test dessus, vérifiez que tous les cas passent au vert, et, pendant une seconde, vous vous sentez terminé. c’est exactement à cet endroit que cela devient intéressant.
newton permet aux développeurs d’écrire des politiques d’autorisation en rego, la même langue de politique que de nombreuses équipes de conformité d’entreprise utilisent déjà en dehors de la crypto. c’est, franchement, un choix sensé ici. ces politiques sont évaluées par un moteur basé sur rust, dérivé du projet regorus de microsoft, étendu avec des builtins propres à newton pour les contrôles crypto, identité, confidentialité et temps. le cli de newton inclut même un flag non strict, spécifiquement pour que sa commande regorus locale puisse se comporter de manière compatible avec opa — ce qui est une admission discrète que le comportement par défaut ne l’est pas. et le guide de tests de newton vous dit, comme toute première étape, de tester unitairement votre rego avec opa test, la véritable implémentation de référence, avant que quoi que ce soit de spécifique à newton ne touche la politique.
Regorus, d’après ce que disent ses mainteneurs, est surtout compatible avec OPA, mais pas totalement. Il passe la suite réelle de conformité OPA pour la plupart des builtins, mais pas tous, et la documentation de Newton liste des catégories entières comme non encore prises en charge dans son build : le hachage crypto et les fonctions hmac standard, l’encodage et la vérification JWT, http.send, net.*, json.patch, graphql, les builtins du fournisseur aws, l’introspection de métadonnées propre à Rego. Newton vous renvoie vers ses propres extensions. Rien de tout cela n’est un cas limite obscur. crypto.hmac.equal, par exemple, est la façon “livre” de comparer deux MAC de manière sûre du point de vue temporel en Rego, documentée noir sur blanc sur le site d’OPA.
Cela dit clairement : une partie de ce manque est volontaire, pas un retard. Regorus exclut les builtins cryptographiques par conception, pour des environnements de calcul confidentiel qui veulent un contrôle strict sur ce qu’il y a dans la base de calcul de confiance. C’est une vraie justification sécurité, pas de la paresse. Mais ça ne change rien à ce qui arrive à quiconque utilise cette fonction sans savoir dans quelle catégorie elle tombe.
Imaginez la séquence. Un auteur de politique doit confirmer qu’une charge utile d’oracle n’a pas été altérée, et se tourne vers crypto.hmac.equal parce que c’est vers là que pointe toute référence Rego. Il écrit une politique compagnon policy_test.rego, lance opa test, regarde le test passer, parce que opa test est littéralement l’implémentation de référence qui se vérifie elle-même par rapport à sa propre sémantique. Rien dans cette étape ne touche le moteur de Newton. La politique semble terminée. Ce n’est qu’une fois déployée et évaluée par le build de regorus de Newton que le même appel échoue à se résoudre, parce que cette primitive particulière n’a jamais été incluse dans la fourche. Et voici la partie à laquelle je reviens sans cesse : plus votre Rego est correctement conforme d’un point de vue “livre”, plus vous êtes exposé, car c’est précisément la norme, les builtins documentés et bien connus que Newton n’a pas encore intégrés qui vous mettent en risque — pas les builtins spécifiques à Newton, qui, eux, fonctionnent évidemment. Qui aurait cru que s’appuyer sur la fonction plus standard serait l’option la plus risquée ?
Je pense que c’est surtout un problème de chaîne d’approvisionnement déguisé en problème de tests. OPA est la spécification originale et la vérité terrain, écrite en Go. Regorus est une réimplémentation Rust de cette spécification, vérifiée contre la suite de conformité d’OPA mais, d’après ses propres dires, incomplète, construite et maintenue par Microsoft. Newton fork Regorus à nouveau par-dessus et ajoute ses propres builtins. Et honnêtement, l’écart suit probablement la logique de feuille de route de Newton plus que n’importe quelle négligence : livrer des builtins d’identité et de confidentialité que n’aucun autre runtime Rego n’a, c’est un travail différenciant qui mérite d’être financé, tandis que courir après une parité complète sur des builtins génériques qui ne sont pas encore une priorité, c’est le genre peu glamour qui attend. Chaque saut dans cette chaîne peut discrètement faire tomber une parcelle de la garantie que la couche au-dessus avait donnée, et le développeur qui écrit un seul fichier Rego n’a une visibilité directe que sur le premier maillon : celui avec le terrain de jeu public et la CLI familière.
Le manque n’est pas vraiment caché, pour être honnête. Il est catalogué, fonction par fonction, dans le guide syntaxique Rego de Newton, avec une alternative nommée pour presque chaque catégorie manquante. Mais un catalogue sur une page de référence et un avertissement dans l’outil que vous avez déjà ouvert, ce sont deux choses différentes. Le workflow complet recommandé par Newton va plus loin que “opa test” seul : jusqu’à un appel newt_simulatePolicy qui exécute toute la politique contre de vraies conditions réseau Newton avant tout déploiement, et cette étape aurait précisément détecté ce problème. Donc la version honnête n’est pas que l’information n’existe pas. C’est que l’étape la plus rapide et la plus réflexe du processus est précisément celle qui ne peut pas voir la couche où se situe l’échec réel.
D’accord, crédit là où il faut. Obtenir une réimplémentation en Rust de Rego qui passe la suite de conformité d’OPA elle-même, sur une demi-douzaine de liaisons de langages, sans emporter un runtime Go, c’est une réussite d’ingénierie réellement rare, pas un projet annexe précipité. Et Newton n’a pas enterré l’écart quelque part de pratique à manquer : il a écrit ce qui manque et quoi utiliser à la place, catégorie par catégorie. Réutiliser un langage de politique existant et bien compris au lieu d’inventer quelque chose de propriétaire, c’est aussi, franchement, le choix le plus généreux pour les développeurs, même si l’écart de conformité se situe dans ce langage.
Empiler une couche d’extension conçue pour l’usage au-dessus d’une réimplémentation partielle de la spécification de quelqu’un d’autre, c’est peut-être simplement une façon raisonnable de livrer une fonctionnalité spécifique rapidement. Ou peut-être que c’est exactement le mouvement qui transforme discrètement des tests sur OPA, avant votre déploiement, d’une étape de sécurité en quelque chose d’incomplet — sans que la personne qui écrit la politique ne s’en rende jamais compte.