OPA Open Policy Agent : définition, Rego et cas d'usage 2026

OPA (Open Policy Agent) est un moteur de décision de politiques open-source, polyvalent, gradué CNCF depuis février 2021 et devenu le standard de fait du policy-as-code dans l'écosystème cloud-native en 2026. Créé par Styra en 2016, il permet de déclarer des règles d'autorisation, de conformité et de validation dans un langage dédié nommé Rego, puis de les évaluer sur des données d'entrée JSON indépendamment du système qui les applique — Kubernetes, Terraform, API Gateway, microservices, CI/CD. Sa force principale est le découplage entre la décision de politique et son application, permettant de réutiliser les mêmes règles sur tous les systèmes d'une organisation. Cet article définit précisément OPA, explique son architecture, introduit le langage Rego, détaille OPA Gatekeeper pour Kubernetes, compare les alternatives (Kyverno, Cedar, ValidatingAdmissionPolicy), et donne les bonnes pratiques de déploiement en production.

Qu'est-ce qu'OPA exactement

OPA est un moteur d'évaluation de politiques (policy engine), pas un outil de sécurité spécifique. Il répond à une question simple mais universelle dans les architectures modernes : étant donné un input JSON décrivant une situation, cette situation est-elle autorisée selon les règles que j'ai déclarées ?

Architecture conceptuelle

   +----------------------+
   |   Application ou     |
   |   Infrastructure     |
   |   (K8s, Terraform,   |
   |    microservice...)  |
   +----------+-----------+
              | (1) input JSON
              v
   +----------+-----------+
   |        OPA           |
   |   Policy Engine      |
   |   (évaluation Rego)  |
   +----------+-----------+
              ^ policies Rego
              v
   +----------+-----------+
   |   Decision JSON      |
   |   (2) allow/deny,    |
   |   reasons, context   |
   +----------------------+

L'application fournit une situation (la requête HTTP à autoriser, le manifest Kubernetes à admettre, le plan Terraform à valider). OPA évalue cette situation contre les politiques Rego chargées en mémoire et retourne une décision structurée. L'application décide ensuite quoi faire de la décision : bloquer, laisser passer, loguer, muter.

Propriétés clés

Comment fonctionne OPA

OPA s'appuie sur trois composants fondamentaux : le moteur d'évaluation, les politiques Rego, et les données contextuelles.

Moteur d'évaluation

Compile les politiques Rego en une représentation interne optimisée. Chaque requête d'évaluation est traitée en quelques microsecondes sur une machine moderne, permettant des milliers de décisions par seconde sur un nœud standard.

Politiques Rego

Les règles métier sont écrites en Rego et regroupées en packages. Elles peuvent être chargées depuis des fichiers locaux, depuis un bundle HTTP signé, ou depuis un serveur de gestion centralisée (Styra DAS ou équivalent).

Données contextuelles

En plus de l'input de la requête, OPA peut charger des données statiques (JSON) : liste des utilisateurs autorisés, matrice de rôles, catalogue de registries approuvés. Ces données sont mises à jour en arrière-plan via le Bundle API.

Modes de déploiement

Le langage Rego en pratique

Rego est un langage déclaratif, inspiré de Datalog et de la programmation logique. Comprendre ses mécanismes fondamentaux est indispensable pour écrire des politiques correctes.

Exemple de politique Rego : autoriser l'accès à une ressource

package auth
 
import future.keywords.if
import future.keywords.in
 
# Regle par defaut : refuser
default allow := false
 
# Regle 1 : les administrateurs peuvent tout faire
allow if {
    input.user.role == "admin"
}
 
# Regle 2 : un utilisateur peut lire ses propres ressources
allow if {
    input.method == "GET"
    input.user.id == input.resource.owner_id
}
 
# Regle 3 : les utilisateurs du groupe finance peuvent lire les rapports
allow if {
    input.method == "GET"
    input.resource.type == "report"
    "finance" in input.user.groups
}

Exemple d'input JSON évalué

{
  "user": {
    "id": "alice",
    "role": "user",
    "groups": ["finance", "hr"]
  },
  "method": "GET",
  "resource": {
    "type": "report",
    "id": "q1-2026-revenue",
    "owner_id": "bob"
  }
}

Évaluation : la règle 1 échoue (pas admin), la règle 2 échoue (owner_id différent), la règle 3 passe (méthode GET, type report, groupe finance présent). OPA retourne allow: true avec les règles qui ont contribué à la décision.

Mécanismes fondamentaux à maîtriser

• Règles : paires key-value où la valeur est calculée à partir d'expressions booléennes.
• Unification : les variables peuvent être liées à des valeurs par correspondance, similaire à Prolog.
• Itération implicite : some i ou variables non-instanciées parcourent automatiquement les collections.
• Helpers : règles utilitaires pour factoriser la logique commune.
• Fonctions intégrées : count(), contains(), regex, JSON path, dates.
• Policies partielles : retourner un résultat partiel indiquant les contraintes restantes, utile pour des applications avancées.

OPA Gatekeeper — le Kubernetes admission controller

OPA Gatekeeper est l'intégration spécialisée d'OPA dans Kubernetes, déployée comme admission controller. Il intercepte les manifests soumis à l'API Kubernetes et les valide (ou les mute) avant qu'ils ne soient persistés dans etcd.

Architecture Gatekeeper

• ConstraintTemplate : CRD qui définit une politique paramétrable en Rego. Exemple : « les pods doivent avoir des labels précis ».
• Constraint : CRD qui instancie un ConstraintTemplate avec des paramètres concrets. Exemple : « tous les pods doivent avoir le label team et le label environment ».
• Config : CRD qui contrôle les namespaces exclus, les ressources synchronisées dans le cache OPA, les options globales.

Exemple de ConstraintTemplate

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
 
        violation[{"msg": msg}] {
          required := input.parameters.labels
          provided := input.review.object.metadata.labels
          missing := required[_]
          not provided[missing]
          msg := sprintf("Missing required label: %v", [missing])
        }

Exemple de Constraint qui instancie la politique

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: pods-must-have-team-and-env
spec:
  enforcementAction: deny
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces:
      - kube-system
      - gatekeeper-system
  parameters:
    labels:
      - team
      - environment

gatekeeper-library : politiques prêtes à l'emploi

Le projet open-policy-agent/gatekeeper-library sur GitHub propose plus de 80 ConstraintTemplates prêts à l'emploi couvrant :

• Baseline Kubernetes (non-root, read-only root FS, host network interdit, capabilities limitées).
• CIS Kubernetes Benchmark compliance.
• Image registry whitelist, tag latest interdit.
• Labels obligatoires, annotations obligatoires.
• Ressources requests/limits obligatoires.
• NetworkPolicy obligatoire par namespace.
• PodDisruptionBudget obligatoire pour les Deployments.
• Conformité sectorielle (PCI-DSS, HIPAA).

Cas d'usage au-delà de Kubernetes

OPA étant généraliste, il s'intègre dans de nombreux systèmes au-delà de Kubernetes.

Validation Terraform via Conftest

Conftest est un outil CLI qui évalue des politiques Rego sur des fichiers de configuration (Terraform, YAML, JSON, Dockerfile, Kubernetes manifests).

# Exemple : valider un plan Terraform contre des politiques Rego
terraform plan -out=plan.tfplan
terraform show -json plan.tfplan > plan.json
conftest test plan.json --policy terraform-policies/

Usage typique : bloquer tout bucket S3 sans chiffrement, toute instance EC2 publique, toute ressource sans tags obligatoires, toute configuration IAM trop permissive.

Autorisation applicative dans les microservices

Pattern documenté par Netflix et Intuit : chaque microservice interroge OPA (REST API locale ou bibliothèque Go embedded) avant d'exécuter une action.

// Exemple Go embedded — demande d'autorisation à OPA
import "github.com/open-policy-agent/opa/rego"
 
func AuthorizeRequest(ctx context.Context, user User, action, resource string) (bool, error) {
    input := map[string]interface{}{
        "user":     user,
        "action":   action,
        "resource": resource,
    }
    rs, err := authQuery.Eval(ctx, rego.EvalInput(input))
    if err != nil {
        return false, err
    }
    return rs.Allowed(), nil
}

API Gateway Envoy et service mesh Istio

Envoy et Istio supportent l'intégration OPA en mode ext_authz : toute requête HTTP entrante est soumise à OPA pour autorisation avant d'atteindre le service backend. Documentation officielle OPA couvre les patterns Envoy et Istio.

CI/CD pipelines

Intégration GitHub Actions, GitLab CI, Jenkins pour valider des politiques organisationnelles : qui peut pusher sur quelle branche, qui peut merger, quels artefacts peuvent être publiés, quelles dépendances sont autorisées.

OPA vs Kyverno vs Cedar vs ValidatingAdmissionPolicy

Quatre moteurs de policy-as-code coexistent en 2026 dans l'écosystème cloud-native. Choisir est stratégique.

Recommandation par cas d'usage

• Kubernetes uniquement, équipe junior ou peu de temps pour apprendre Rego → Kyverno.
• Kubernetes + Terraform + microservices + API Gateway avec cohérence de règles → OPA.
• AWS-heavy avec IAM fin-granulaire et moins de Kubernetes → Cedar.
• Politiques Kubernetes simples sans dépendance externe → ValidatingAdmissionPolicy natif 1.30+.
• Grande entreprise multi-cloud avec gouvernance centralisée → OPA + Styra DAS commercial.

Intégration dans un pipeline CI/CD

Un pipeline DevSecOps mature exploite OPA à plusieurs niveaux.

name: DevSecOps with OPA
on:
  pull_request:
    branches: [main]
 
jobs:
  opa-validations:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Setup OPA CLI
        uses: open-policy-agent/setup-opa@v2
        with:
          version: latest
 
      - name: Validate Kubernetes manifests
        run: |
          opa eval --data policies/k8s/ --input manifests/deployment.yaml \
            "data.kubernetes.admission.deny"
 
      - name: Validate Terraform plan
        run: |
          terraform plan -out=tfplan
          terraform show -json tfplan > tfplan.json
          opa eval --data policies/terraform/ --input tfplan.json \
            "data.terraform.analysis.deny"
 
      - name: Validate Dockerfile with Conftest
        run: |
          conftest test Dockerfile --policy policies/docker/
 
      - name: Validate GitHub Actions workflow
        run: |
          opa eval --data policies/ci/ --input .github/workflows/main.yaml \
            "data.ci.security.deny"

Écosystème Styra et outils connexes

Styra est l'entreprise créatrice d'OPA. Elle propose autour du projet open-source plusieurs produits commerciaux et outils.

Concurrents Rego (même esprit, autre langage)

• Cerbos : moteur de policy-as-code focus applicatif, YAML-driven.
• Permit.io : plateforme policy-as-service avec UI non-technique.
• SpiceDB (Zanzibar clone) : autorisation fine-grained, inspiré Google Zanzibar.

Pièges courants

Écrire des politiques monolithiques dans un seul fichier. Rego supporte le packaging. Organiser par domaine : package auth.api, package kubernetes.admission, package terraform.aws. Faciliter les tests unitaires et la réutilisation.

Ignorer les tests unitaires Rego. Rego dispose d'un framework de test natif (opa test) souvent négligé. Couvrir chaque règle avec des cas positifs et négatifs, particulièrement les chemins d'autorisation critiques. Objectif : 80 % de couverture sur les règles de décision.

Confondre else et règles multiples. Rego n'a pas d'else impératif. Plusieurs règles avec le même nom sont ou-ées (logique OR). Cette subtilité cause des bugs silencieux en rédaction.

Ne pas versionner les politiques. Les politiques Rego sont du code. Elles doivent vivre dans un Git, passer par PR, être code-reviewées, signer les bundles OPA en production (intégrité des politiques chargées).

Charger des politiques trop gourmandes. Une itération quadratique sur un tableau de 10 000 éléments prend 100 ms. À l'échelle de 1 000 requêtes/s, OPA sature. Profiler avec opa eval --explain full pour identifier les goulots.

Mélanger Rego v0 et Rego v1. Rego v1 (par défaut depuis OPA 1.0 en janvier 2025) impose if et in pour les règles. Les politiques v0 historiques restent lisibles avec import rego.v1 mais les équipes doivent migrer progressivement.

Ignorer le cache et les patterns partiels. Pour les décisions haute fréquence (milliers par seconde), utiliser l'évaluation partielle pour pré-compiler les décisions en SQL ou règles plus rapides.

Points clés à retenir

• OPA = moteur généraliste de décision de politiques, CNCF Graduated (février 2021), langage Rego, standard de fait du policy-as-code cloud-native en 2026.
• Découplage décision / application : les mêmes politiques Rego servent Kubernetes, Terraform, microservices, API Gateway, CI/CD.
• Rego : déclaratif, inspiré Datalog, courbe d'apprentissage moyenne à élevée (20-40 heures pour maîtrise opérationnelle).
• OPA Gatekeeper : admission controller Kubernetes basé sur OPA, remplace les PSP dépréciées, bibliothèque gatekeeper-library avec 80+ templates prêts.
• Alternatives : Kyverno (plus simple, K8s-only), Cedar (AWS IAM), ValidatingAdmissionPolicy (K8s natif 1.30+). Kyverno prend des parts sur le pur use case Kubernetes.
• Cas d'usage multi-systèmes : validation Terraform via Conftest, autorisation microservices (Netflix, Intuit), API Gateway Envoy/Istio, CI/CD policies.
• Styra : entreprise créatrice, propose Styra DAS (gestion centralisée commerciale) et Styra Academy (formation gratuite).
• Bonnes pratiques : packaging clair, tests unitaires Rego, versionning Git, signature bundles, monitoring performance, migration progressive v0 → v1.

Pour aller plus loin

• Outils DevSecOps à connaître en 2026 — positionnement d'OPA dans la stack DevSecOps complète.
• Roadmap DevSecOps 2026 — parcours d'apprentissage incluant OPA et policy-as-code.
• Roadmap Cloud Security 2026 — extension vers la gouvernance cloud multi-compte qui consomme intensivement OPA.
• Secure coding : définition, principes et référentiels 2026 — principes applicatifs complémentaires à la policy-as-code infra.
• Devenir DevSecOps sans expérience — pillar catégorie, point d'entrée global.