Kyverno et OPA/Gatekeeper répondent à la même question : comment valider ou modifier automatiquement une ressource Kubernetes au moment de son admission, avant qu’elle n’entre dans le cluster. Les deux s’appuient sur le même mécanisme sous-jacent (un webhook d’admission), mais expriment les règles de policy dans deux langages radicalement différents.

Kyverno : des policies en YAML natif

Kyverno écrit ses règles dans le même langage que le reste de l’écosystème Kubernetes : du YAML déclaratif, sans langage de requête séparé à apprendre.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-limits
      match:
        resources:
          kinds: [Pod]
      validate:
        message: "Chaque conteneur doit déclarer des limits CPU et mémoire"
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    cpu: "?*"
                    memory: "?*"

Cette syntaxe déclarative rend une policy simple lisible par n’importe qui déjà familier avec des manifests Kubernetes, sans détour par un langage tiers. La contrepartie apparaît sur des règles complexes (logique conditionnelle imbriquée, agrégation entre plusieurs ressources) : le YAML devient vite aussi difficile à suivre que les conditions imbriquées d’un chart Helm trop chargé.

OPA/Gatekeeper : Rego, un langage de requête dédié

Gatekeeper embarque Open Policy Agent (OPA), un moteur de policy généraliste utilisé bien au-delà de Kubernetes (API gateways, CI/CD, autorisation applicative). Les règles s’écrivent en Rego, un langage de requête dédié à l’évaluation de policies :

package kubernetes.limits

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not container.resources.limits.cpu
  msg := "Chaque conteneur doit déclarer une limit CPU"
}

Rego a une courbe d’apprentissage réelle, distincte de tout ce qu’un ingénieur Kubernetes connaît déjà. Le bénéfice apparaît sur les règles complexes : Rego exprime naturellement de la logique d’agrégation, de la composition de policies et des tests unitaires (opa test) qui restent artificiels à simuler en YAML pur. L’avantage se combine avec la portabilité : la même policy Rego peut, en théorie, s’appliquer ailleurs que sur des ressources Kubernetes.

Le vrai critère : la complexité des règles, pas la préférence

Une équipe qui écrit surtout des règles simples (types de ressources interdits, champs obligatoires, labels requis) tire peu de bénéfice de la puissance de Rego et paie le coût d’apprentissage sans contrepartie réelle : Kyverno résout ce cas en quelques lignes de YAML, lisibles par toute l’équipe sans formation dédiée. Une équipe qui doit exprimer des règles inter-ressources complexes (une contrainte qui dépend de plusieurs objets liés, une logique de policy réutilisée hors Kubernetes) trouve dans Rego une expressivité que le pattern-matching YAML de Kyverno n’a pas vocation à couvrir.

Ce qui ne change pas selon l’outil choisi

Le mode d’application (Enforce qui bloque une ressource non conforme contre Audit qui journalise sans bloquer) existe dans les deux outils, avec la même logique de rollout progressif : démarrer en mode audit sur un cluster existant pour mesurer l’impact réel avant de bloquer quoi que ce soit en production. Sauter cette étape et passer directement en mode strict est la cause la plus fréquente d’un déploiement métier bloqué par une policy de sécurité que personne n’avait testée contre la réalité du cluster.

À retenir

Kyverno et OPA/Gatekeeper valident les mêmes admissions Kubernetes par deux langages opposés : YAML natif, lisible immédiatement mais limité sur la logique complexe, contre Rego, plus puissant mais avec une vraie courbe d’apprentissage. Le critère de choix est la complexité réelle des règles que l’équipe doit exprimer, pas une préférence de syntaxe. Les deux se déploient en mode audit avant enforce, une discipline qui compte plus que l’outil lui-même dans le cadre d’une industrialisation CI/CD.