Un développeur pousse un déploiement avec une image taguée latest, sans requests ni limits, en privileged: true. Sur un cluster sans garde-fou, ça passe. En prod, ça donne un pod qui peut saturer un nœud, qu'on ne sait pas reproduire à l'identique parce que latest a bougé depuis, et qui tourne avec les pleins pouvoirs sur l'hôte. La policy-as-code existe pour bloquer ces trois fautes avant qu'elles n'atteignent l'API server. Kyverno le fait en YAML, sans imposer d'apprendre un langage dédié.
Un policy engine qui parle Kubernetes
Kyverno est un moteur de politiques natif Kubernetes, projet CNCF, passé au statut graduated le 24 mars 2026. Il rejoint la cour des Kubernetes, Prometheus, Envoy et Helm dans le plus haut niveau de maturité de la fondation. Près de quatre ans d'incubation derrière lui, ce n'est pas un jouet : LinkedIn traite plus de 20 000 requêtes d'admission par minute via Kyverno sur 230 clusters et plus de 500 000 nœuds. Bloomberg, Coinbase, Deutsche Telekom, Spotify, Vodafone et Wayfair figurent parmi les adoptants cités lors de la graduation.
Le parti pris qui le distingue : les politiques s'écrivent en YAML natif Kubernetes. Une politique Kyverno est une ressource Kubernetes comme une autre, dans le même format que vos manifests. Pas de langage séparé à apprendre, pas de DSL à maîtriser pour l'équipe applicative. Vous savez écrire un manifest, vous savez lire une politique Kyverno. Cette barrière à l'entrée plus basse change qui peut écrire des règles : pas seulement la plateforme, les équipes applicatives aussi.
Quatre actions, un seul système
Kyverno couvre quatre types d'opérations dans le même moteur, et c'est cette polyvalence qui fait sa valeur.
Le validate accepte ou rejette une ressource selon des critères. C'est le réflexe premier : refuser un pod privilégié, exiger un label, bloquer un namespace non conforme.
Le mutate modifie la ressource à l'admission. Injecter des defaults, ajouter une securityContext, poser des labels manquants. La règle s'applique avant que la ressource ne soit persistée.
Le generate crée des ressources compagnes automatiquement. À la création d'un namespace, générer la NetworkPolicy par défaut, le ResourceQuota, le RoleBinding. C'est la fonctionnalité qu'OPA Gatekeeper n'a pas, et elle change la donne pour qui veut une configuration proactive plutôt qu'un simple filtrage.
Le verifyImages vérifie les signatures cosign des images. On boucle ici avec la chaîne d'approvisionnement : une politique Kyverno peut imposer que toute image déployée porte une signature cosign valide, émise par une identité de confiance. La gate de provenance devient une règle d'admission du cluster.
Comment ça branche : l'admission controller
Kyverno s'installe comme un admission controller dynamique, typiquement via un seul chart Helm. Il s'enregistre auprès de l'API server via un ValidatingWebhookConfiguration (et un MutatingWebhookConfiguration pour les mutations). Quand une ressource est créée ou modifiée, l'API server appelle Kyverno avant de persister. La politique tranche : accepter, modifier, rejeter.
Pas de composant tiers à brancher, pas de datastore externe à maintenir : Kyverno tourne dans ses propres pods et l'API server l'appelle via le webhook. C'est un point qui pèse en exploitation : moins de pièces mobiles, moins de modes de panne. Le webhook d'admission reste un point sensible, à surveiller comme tel, mais le déploiement tient en une commande.
Au-delà de l'admission, Kyverno fait du background scan. Activé par défaut via le champ spec.background d'une Policy ou ClusterPolicy, il scanne périodiquement les ressources existantes pour repérer celles qui violeraient une règle validate ou verifyImages. Les violations atterrissent dans un PolicyReport ou un ClusterPolicyReport, selon que la ressource est namespacée ou non. Ça compte : appliquer une politique ne corrige pas le parc déjà déployé avant elle. Le background scan rend visibles les ressources non conformes existantes, sans les casser. On voit l'écart avant de le réduire.
Le complément naturel, c'est Policy Reporter, l'outil d'observabilité du CRD PolicyReport. Il expose les violations vers Grafana Loki, Elasticsearch, Slack, un endpoint de métriques, et fournit un dashboard de l'état de conformité. La gouvernance du cluster devient mesurable, pas déclarative.
Cas concrets
Ce qu'on déploie en premier sur un cluster qu'on reprend, ce sont quelques politiques de base qui ferment les fautes les plus courantes.
Interdire le tag latest : une règle validate qui refuse toute image dont le tag est latest ou absent. Fin des déploiements non reproductibles.
Imposer requests et limits : validate qui rejette tout conteneur sans ressources définies. Fin des pods qui mangent un nœud entier faute de cap.
Vérifier les signatures cosign : verifyImages qui n'accepte que les images signées par votre chaîne de build, en cohérence avec une démarche SLSA de provenance et un scan d'images Trivy en amont.
Générer les defaults par namespace : generate qui crée NetworkPolicy de deny par défaut et ResourceQuota à chaque nouveau namespace. La sécurité réseau et les quotas par défaut, sans intervention manuelle.
Kyverno ou OPA Gatekeeper
La vraie question n'est pas « lequel est meilleur » mais « lequel pour quel contexte ». OPA Gatekeeper utilise Rego, un langage dédié à la décision de politique. Rego est plus expressif : pour une logique complexe, des jointures entre ressources, une politique qui raisonne sur un état large, il va plus loin que ce que le YAML déclaratif de Kyverno permet d'exprimer proprement. Le prix : une courbe d'apprentissage réelle. Rego ne ressemble à rien de ce qu'une équipe Kubernetes connaît déjà.
Gatekeeper s'articule autour des ConstraintTemplate (le code Rego réutilisable) et des Constraint (l'instanciation avec paramètres et sélecteur). Architecture propre, mais une indirection de plus, et le Rego à maîtriser. Côté fonctionnalités, Gatekeeper ne génère pas de ressources et se concentre sur la validation à l'admission, là où Kyverno mute, génère et scanne l'existant.
Le critère de tranche : si vous êtes Kubernetes-only et que vous voulez que les équipes applicatives écrivent leurs propres politiques, Kyverno. Le YAML abaisse la barrière, la génération de ressources et le background scan couvrent des besoins que Gatekeeper laisse de côté. Si vous avez besoin de l'expressivité du Rego pour une logique vraiment complexe, ou si OPA est déjà votre standard de policy au-delà de Kubernetes (API gateways, microservices, autorisation applicative), Gatekeeper garde sa place pour la cohérence d'outillage.
Le verdict ops
Pour de la policy Kubernetes pure, YAML-first, Kyverno gagne. Statut CNCF graduated, déploiement en un chart, quatre actions dans un seul moteur, et surtout une syntaxe que toute l'équipe sait déjà lire. Le combo verifyImages plus background scan en fait plus qu'un filtre d'admission : un outil de gouvernance continue du cluster, qui voit l'existant et pas seulement le flux entrant.
On ne sort d'OPA Gatekeeper que dans deux cas précis : une logique de politique qui dépasse ce que le déclaratif exprime sans contorsion, ou un standard OPA déjà en place sur le reste de la stack qu'on veut garder homogène. Hors de là, imposer Rego à une équipe Kubernetes pour interdire le tag latest, c'est de la complexité gratuite. Et la complexité gratuite, en prod, c'est de la dette d'exploitation.
Quitte à poser des garde-fous, autant qu'ils tiennent dans la durée : politiques versionnées, background scan branché sur la supervision, signatures d'images contrôlées de bout en bout. C'est ce qu'on monte sur les clusters Kubernetes qu'on opère, avec une détection runtime comme Falco en complément de l'admission, et une gestion des secrets via External Secrets plutôt que des secrets en clair dans les manifests.
Sources
- Kyverno, site officiel : documentation des politiques, des quatre actions et de l'architecture admission controller.
- CNCF Announces Kyverno's Graduation : la graduation CNCF de mars 2026 et les chiffres d'adoption.
- kyverno/kyverno, dépôt GitHub : code source, capacités et liste des adoptants.
- Policy Reports, documentation Kyverno : background scans, PolicyReport et observabilité de la conformité.
- Kubernetes Policy Comparison: Kyverno vs OPA/Gatekeeper, Nirmata : comparatif détaillé Rego contre YAML et critères de choix.
