Open Policy Agent pour les MSP : admission, autorisation API et portes CI

Open Policy Agent (OPA) est surtout connu comme le moteur derrière le contrôle d'admission Kubernetes, mais le projet principal n'a rien de spécifique à Kubernetes. Ce guide s'adresse aux MSP et aux équipes plateforme qui souhaitent utiliser OPA comme moteur de politiques généraliste — pour l'autorisation API, les contrôles CI et l'admission Kubernetes — sans confondre le rôle de chaque outil, avec en plus ce qu'a changé un récent correctif du parseur pour ceux qui utilisent déjà la nouvelle syntaxe Rego d'OPA.

Où OPA intervient au-delà de Kubernetes

Le projet principal — open-policy-agent/opa sur GitHub, avec environ 12,3 mille étoiles et 1,7 mille forks — est un moteur de politiques qui évalue une requête par rapport à une politique écrite plutôt qu'à une logique applicative codée en dur. Les MSP et les équipes produit l'utilisent partout où ce type de décision doit être pris, pas seulement en bordure d'un cluster Kubernetes.

Le même langage de politiques Rego qu'il exécute fonctionne tout aussi bien sur une passerelle API ou dans un sidecar de service, en évaluant si une requête est autorisée avant qu'elle n'atteigne le code de l'application. Vous pouvez réutiliser les mêmes paquets de politiques dans des pipelines CI pour détecter des violations, comme une dépendance interdite, une ressource mal configurée ou une région non approuvée, avant qu'un changement ne soit déployé plutôt qu'après.

OPA, Gatekeeper et Conftest sont trois choses différentes

Le contrôle d'admission Kubernetes via Gatekeeper est une intégration construite au-dessus d'OPA, pas OPA lui-même, et Conftest est un outil en ligne de commande distinct pour tester des fichiers de configuration structurés par rapport à des politiques Rego. Réunir les trois en une seule histoire OPA dans du contenu destiné aux clients exagère ce que fait chaque outil pris isolément : chacun a son propre modèle de déploiement et ses propres modes de défaillance.

Gatekeeper : appliquer les politiques à la porte d'entrée de Kubernetes

OPA Gatekeeper, maintenu au sein de l'organisation Open Policy Agent sur GitHub avec environ 4,3 mille étoiles, est un contrôleur d'admission Kubernetes. Il intercepte les requêtes API via un webhook d'admission de validation et les vérifie par rapport à des politiques Rego au moment où une charge de travail est soumise, plutôt qu'après qu'elle soit déjà en cours d'exécution. Pour un MSP qui gère plusieurs clusters clients, une règle peut être écrite une fois et appliquée de façon cohérente : exiger que les images de conteneur proviennent d'un registre approuvé ou portent une attestation de signature vérifiée, refuser les conteneurs qui demandent le mode privilégié ou des montages hostPath sans restriction, ou limiter les types de charge de travail qu'un espace de noms donné peut accepter.

Gatekeeper est une intégration spécifique à Kubernetes, pas un substitut au moteur principal, que les MSP utilisent aussi pour l'autorisation API et les contrôles CI en dehors de Kubernetes ; les deux sont complémentaires, Gatekeeper prenant en charge le chemin d'admission pendant que le moteur principal prend les décisions de politique ailleurs dans la pile. Il ne remplace pas non plus RBAC, la politique réseau ou l'hygiène des secrets : il ajoute une couche par-dessus, pas à leur place.

Septembre 2026 : un bug du parseur corrigé dans OPA 1.20.2

OPA 1.20.2, publiée début septembre 2026, corrige un bug du parseur introduit deux versions plus tôt dans la 1.20.0, qui avait ajouté les nouveaux mots-clés Rego and et or pour combiner des conditions au sein d'un même corps de règle. Lorsqu'une politique importait ces mots-clés, directement ou via import future.keywords, le parseur d'OPA lisait d'abord une instruction commençant par une accolade comme corps d'un opérande, puis la relisait comme un terme, par exemple une compréhension, si ni and ni or ne suivait.

Une régression faisait que les erreurs enregistrées lors de cette première lecture abandonnée restaient en cache et étaient signalées à tort lors de la seconde lecture, celle qui réussissait, ce qui amenait le parseur à rejeter des politiques pourtant valides. Les politiques qui n'importent pas and/or n'ont jamais été concernées, et il s'agit d'un correctif ciblé, pas d'un avis de sécurité ; le projet complémentaire opa-envoy-plugin a publié en parallèle une version v1.20.2-envoy correspondante, donc si vous utilisez ce plugin, vérifiez que vous avez reçu la même mise à jour de version.

Les MSP qui souhaitent une vérification externe de ces contrôles dans le cadre d'un programme de conformité NIS2, DORA ou RGPD peuvent s'appuyer sur un accompagnement dédié : les services de cybersécurité d'Altovar couvrent les tests d'intrusion, l'évaluation des vulnérabilités, la réponse aux incidents et le travail de conformité pour ces mêmes référentiels.

Points de départ pratiques

• Autorisation API : évaluez les politiques Rego au niveau de la passerelle ou du sidecar pour les requêtes qui nécessitent des règles par tenant ou par rôle au-delà de l'authentification intégrée d'un framework.
• Portes de politique en CI : exécutez les mêmes règles Rego sur de l'infrastructure-as-code ou des manifestes dans une étape de pipeline, en faisant échouer le build en cas de violation plutôt qu'en comptant sur une revue manuelle.
• Admission Kubernetes : démarrez les politiques Gatekeeper en mode dry-run ou warn, documentez les exceptions pour les charges de travail existantes et limitez les contraintes à des espaces de noms précis avant de les étendre.
• Bibliothèques de politiques partagées : écrivez les règles une seule fois et appliquez-les à l'admission, à l'autorisation API et à la CI plutôt que de réimplémenter trois fois la même logique.

Que faire

1. Cartographiez où se prennent aujourd'hui les décisions de politique dans votre pile — admission, passerelle, CI — et signalez celles encore codées en dur plutôt que basées sur des politiques.
2. Si vous utilisez Gatekeeper, déployez les nouvelles contraintes en mode dry-run ou warn et documentez les exceptions avant de passer en enforce.
3. Gardez les trois outils distincts dans votre propre documentation : le moteur OPA, Gatekeeper pour l'admission et Conftest pour la CI et les tests de configuration.
4. Si vos politiques Rego importent les mots-clés and/or, vérifiez que vous êtes en version 1.20.2 ou ultérieure avant de considérer un rejet comme une erreur d'écriture.
5. Vérifiez si des outils dépendants, comme le plugin Envoy ou des sidecars, ont reçu la même mise à jour de version d'OPA.
6. Associez les politiques d'admission et d'autorisation à RBAC, à la politique réseau et à l'hygiène des secrets, plutôt que de les considérer comme un substitut complet.

Sources : GitHub — open-policy-agent/opa, GitHub — open-policy-agent/opa releases, GitHub — open-policy-agent/gatekeeper.