Gouvernance Kubernetes dans les environnements multi-cloud : Policy-as-Code avec OPA et Kyverno

13 mai 2026

7 Min. de lecture

Toute entreprise utilisant une configuration multi-cloud avec trois clusters Kubernetes ou plus et documentant encore sa gouvernance sur des pages Confluence court un risque opérationnel en 2026 que les auditeurs NIS2 découvriront dès le premier échantillonnage. La Policy-as-Code avec OPA Gatekeeper ou Kyverno déplace l’application des règles vers le chemin d’admission. Ce qui était auparavant un PDF dans le dossier de conformité devient ainsi du YAML qui vérifie chaque définition de Pod avant même qu’elle ne soit planifiée.

Les points clés en bref

La Policy-as-Code déplace la conformité de l’audit vers la pipeline de build : OPA Gatekeeper et Kyverno s’intègrent comme Admission-Webhook à chaque appel d’API Kubernetes et bloquent les Pods qui violent les spécifications de configuration avant qu’ils ne soient planifiés.
Multi-Cloud signifie plusieurs moteurs de politiques ou une couche de plateforme unifiée : EKS, AKS et GKE apportent chacun leurs propres règles par défaut. Pour appliquer la gouvernance de manière cohérente sur les trois ensembles de clusters, il faut soit un hub de politique centralisé, soit des pipelines GitOps qui poussent des règles identiques sur chaque cluster.
La différence entre OPA Gatekeeper et Kyverno est opérationnelle, pas idéologique : Gatekeeper nécessite Rego comme DSL et une équipe qui maîtrise fiablement ce langage. Kyverno fonctionne avec des modèles YAML que chaque ingénieur de plateforme peut lire sans formation. La décision repose presque toujours sur la disponibilité des compétences, pas sur les listes de fonctionnalités.

Liens connexes :Multi-Cluster sans nouveau silo Ops / Checklist de migration Kubernetes 1.36

Pourquoi la dérive de conformité dans les environnements multi-cloud K8s se produit plus vite qu’on ne le pense

Dans les articles que nous publions depuis début 2026 dans cloudmagazin, un modèle apparaît que la plupart des équipes de plate sous-estiment. Quiconque gère trois ensembles de clusters via EKS, AKS et GKE finit par avoir trois configurations par défaut légèrement différentes pour les standards de sécurité des Pods. Une petite divergence dans la définition de `runAsNonRoot`, un comportement différent avec les jetons de compte de service automatiques, un chemin de défaut différent pour les stratégies réseau. Individuellement, ces écarts sont anodins. Mais ensemble, ils créent un profil de conformité que plus personne ne documente entièrement.

Les implémentations NIS2 dont nos auteurs ont écrit ces dernières semaines transforment précisément cette lacune de dérive en un sujet d’audit. Il ne suffit plus de montrer qu’une politique existe quelque part. Les auditeurs demandent le mécanisme qui l’applique. Confluence n’est pas une réponse à cela.

La Policy-as-Code avec OPA Gatekeeper ou Kyverno résout le problème en déplaçant la définition des règles vers le point où Kubernetes vérifie de toute façon chaque ressource : le contrôleur d’admission. Ainsi, la conformité devient une étape de build, pas un rendez-vous trimestriel.

OPA Gatekeeper vs. Kyverno : la ligne opérationnelle de démarcation

Les comparaisons théoriques des deux moteurs se retrouvent dans la moitié des enregistrements de conférences DevOps. En pratique, ces outils dessinent d’autres lignes de démarcation que ce que la matrice de fonctionnalités suggère.

Dimension	OPA Gatekeeper	Kyverno
Langage	Rego (DSL propre)	Motifs YAML, natif Kubernetes
Courbe d’apprentissage	Raide, compétences distinctes	Douce, familière pour les ingénieurs plateforme
Stratégies de mutation	Via le mutateur Gatekeeper	Intégré
Réutilisation en dehors de K8s	Oui (motifs OPA partout)	Non (uniquement K8s)
Profil d’adéquation	Équipes avec expérience en Rego, moteur de conformité multi-domaines	Équipes plateforme qui doivent déployer rapidement la gouvernance

Ce qui fait systématiquement dévier les migrations de cluster selon les observations de nos auteurs, c’est la question des compétences. Rego est puissant, mais si trois des huit ingénieurs plateforme ne peuvent pas le productivement écrire, la maintenance des politiques devient un goulot d’étranglement. Kyverno atteindre le seuil de lisibilité plus tôt.

Une configuration multi-cloud sans dérive de politiques : quatre étapes

Versionner centraliser la bibliothèque de politiques. Un seul dépôt Git contient tous les ConstraintTemplates ou ClusterPolicies. Chaque cluster est consommateur, aucun cluster n’est propriétaire. Celui qui gère localement les politiques par cluster aura en six mois trois définitions différentes pour la même règle.
Push GitOps au lieu de kubectl apply manuel. Argo CD ou Flux déploient la bibliothèque de politiques sur chaque cluster. Ainsi, l’état du cluster est une fonction de l’état Git, et on répond aux questions d’audit avec un journal Git plutôt qu’une capture d’écran.
Mode audit avant mode application. Les nouvelles politiques s’exécutent pendant au moins deux semaines en mode avertissement. Les rapports montrent quels workloads existants violeraient la règle. Seule lorsque la liste d’impact est vide ou explicitement exclue, la politique passe en mode bloquant.
Détection de dérive comme couche séparée. Même avec GitOps, il y a des modifications ad hoc qui passent brièvement à côté du contrôleur. Un rapport de dérive hebdomadaire (par exemple, Argo-CD-Diff, Kyverno-Reports-API) montre chaque écart. Sans cette couche, le multi-cluster devient flou avec le temps.

Les deux premières étapes sont obligatoires. L’étape trois évite le piège standard où les politiques dérangent en production et bloquent simultanément quatre équipes. L’étape quatre fait la différence entre une démonstration de conformité et une configuration qui reste cohérente même après 18 mois.

Ce qui décide vraiment les équipes de plateforme dans le choix de l’engine 2026

Dans les recherches menées par nos auteurs avec les responsables de plateformes DACH, trois piliers de décision sont apparus, qui rarement figurent dans les présentations de conférence.

Premièrement, la question de savoir si l’équipe de plateforme applique déjà la conformité pour les workloads non Kubernetes (plans Terraform, politiques IAM, pipelines CI). Si oui, OPA est le levier naturel, car Rego couvre toutes ces domaines. Si l’univers de la conformité est purement Kubernetes, il y a peu de raisons à introduire une deuxième DSL.

Deuxièmement, la taille et la répartition des seniors dans l’équipe. Une équipe de trois ingénieurs dont seul un écrit correctement du Rego est mieux servie avec Kyverno. Dès que cet ingénieur est en vacances ou démissionne, la maintenance des politiques est négligée. Les fichiers YAML Kyverno survivent beaucoup mieux au turnover du personnel.

Troisièmement, l’outillage de sécurité existant. Ceux qui ont déjà Falco, Trivy ou les standards de sécurité de Pod dans leur pipeline ont souvent des attentes en matière de reporting que Kyverno remplit nativement avec les CRDs de rapport. Gatekeeper offre ici moins de fonctionnalités prêtes à l’emploi.

Foire aux questions

La Policy-as-Code est-elle déjà rentable avec un seul cluster Kubernetes ?

Oui, dès que le cluster supporte des workloads de production pour plus d’une équipe. Sans Admission-Controller, la responsabilité de la cohérence migre vers chaque manifeste individuel. Avec Policy-as-Code, cela devient une caractéristique de la plateforme. Pour un cluster de laboratoire, la surcharge est trop importante, pour un setup multi-locataires, c’est obligatoire.

Quel est le surcoût de performance dû aux Admission-Webhooks ?

Dans des configurations bien établies, la latence d’admission supplémentaire se situe dans la plage de quelques millisecondes par création de Pod. Cela ne devient critique qu’avec les opérations en masse (par exemple les Helm-Releases avec des centaines de ressources) ou avec des modèles de contraintes très complexes. Les deux moteurs supportent le caching et la réconciliation en arrière-plan.

OPA et Kyverno peuvent-ils fonctionner en parallèle sur le même cluster ?

Techniquement oui, les deux s’enregistrent comme des webhooks différents. Opérationnellement, cela a rarement du sens. Des politiques dupliquées entraînent des confusions lors du débogage, des couches d’audit dupliquées doublent la maintenance. Si un chemin de migration est nécessaire, fonctionnez en parallèle, sinon consolidez sur un seul moteur.

Que se passe-t-il si le Admission-Webhook tombe en panne ?

Cela dépend du paramétrage `failurePolicy`. Sur `Fail`, chaque panne de webhook bloque le cluster pour de nouveaux Pods. Sur `Ignore`, les politiques sont contournées lors d’une panne de webhook, ce qui, dans le pire des cas, crée des lacunes de conformité. La meilleure pratique pour la production est `Fail` plus haute disponibilité du déploiement du webhook. Un setup à single-Pod pour un cluster multi-locataires est négligent.

La Policy-as-Code suffit-elle seule pour la conformité NIS2 ?

Non, mais elle couvre une grande partie des obligations techniques de preuve. NIS2 exige en plus des processus de réponse aux incidents, la gestion des fournisseurs et la production de rapports. La Policy-as-Code fournit la preuve technique de l’application des configurations de sécurité, ce qui réduit considérablement la charge d’audit. L’aspect organisationnel reste inchangé.