~12 minutes
Cet article fait partie de la série Sécurité Kubernetes. Si vous cherchez l’introduction et le sommaire complet, commencez par là.
Kubernetes a beau disposer de mécanismes de sécurité natifs, la gouvernance des ressources reste un défi : comment s’assurer qu’aucun Pod ne tourne en root, que toutes les images sont signées, que les namespaces respectent des quotas, et tout ça sans transformer chaque pull request en chasse au trésor manuelle ?
En 2026, Kyverno a sérieusement grandi. Si vous l’avez évalué il y a deux ans et laissé de côté, c’est le moment de reconsidérer.
Pourquoi Kyverno reste incontournable
La promesse de Kyverno est simple : écrire des policies Kubernetes dans le même langage que les ressources Kubernetes, c’est-à-dire en YAML. Pas de DSL exotique, pas d’apprentissage de Rego ou d’un autre langage de contraintes ; les équipes qui savent déjà écrire un Deployment ou un NetworkPolicy peuvent écrire des policies Kyverno le même jour.
C’est une différence fondamentale avec OPA/Gatekeeper, qui impose Rego. Rego est puissant, mais compliquée pour les SRE/OPS….. Kyverno mise sur la proximité avec l’écosystème Kubernetes : les règles ressemblent à des manifest, les conditions ressemblent à des sélecteurs, et les exceptions ressemblent à des annotations. Le résultat, c’est une adoption beaucoup plus facile et rapide dans les équipes qui ne sont pas composées de spécialistes OPA/Rego.
En 2026, un troisième compétiteur est devenu sérieux : la ValidatingAdmissionPolicy (VAP) native Kubernetes. Stable depuis Kubernetes 1.28, VAP permet d’exprimer des règles de validation directement dans l’API Kubernetes, sans admission webhook externe. On y reviendra , mais l’essentiel est là : Kyverno et VAP ne sont pas vraiment concurrents sur toute la ligne. Kyverno couvre des cas que VAP ne touche pas (mutation, génération, vérification d’images), et les deux peuvent coexister sur un même cluster.
L’approche pragmatique : les validations simples sans mutation ni génération vont dans VAP, les workflows de gouvernance complets restent dans Kyverno. Les deux coexistent sans frictions sur un même cluster.
Les différents modes d’actions de Kyverno
Kyverno ne fait pas que bloquer. L’outil couvre quatre types d’actions sur les ressources Kubernetes :
| Mode | Ce que ça fait | Exemple d’usage typique |
|---|---|---|
| Validate | Bloque ou audite les ressources qui ne respectent pas une règle | Interdire les images avec le tag latest, exiger des labels obligatoires |
| Mutate | Modifie les ressources à la volée pendant l’admission | Ajouter automatiquement des labels, injecter un sidecar, forcer imagePullPolicy: Always |
| Generate | Crée des ressources dérivées quand une ressource cible est créée | Créer un NetworkPolicy par défaut à la création de chaque namespace, dupliquer un Secret dans plusieurs namespaces |
| VerifyImage | Vérifie que les images container sont signées avec Cosign | Bloquer le déploiement de toute image non signée par la CA interne ou via Sigstore keyless |
C’est là que VAP s’arrête et que Kyverno continue. Une ValidatingAdmissionPolicy peut valider, point. Pas de mutation, pas de génération, pas de vérification de signatures. Si vous avez besoin d’une de ces trois capacités, vous avez besoin de Kyverno.
Le mode Audit mérite une mention particulière : toutes les règles Validate peuvent fonctionner en mode Audit plutôt qu’Enforce. En mode Audit, la ressource est acceptée mais une violation est enregistrée dans les PolicyReports. C’est essentiel pour déployer des policies progressivement dans un cluster existant, sans risquer de casser les workloads en place.
Policy Exceptions
La PolicyException est une ressource Kubernetes dédiée qui permet de déclarer explicitement qu’une ressource donnée est exemptée d’une ou plusieurs règles. L’exception est versionnée, visible dans le cluster, auditable. Elle peut être soumise à un workflow d’approbation via GitOps : une équipe ouvre une PR pour créer une PolicyException, la PR est revue par l’équipe sécurité, et l’exception n’est appliquée qu’une fois mergée.
Ce qui est recommandé :
- stocker toutes les PolicyExceptions dans un repository GitOps dédié,
- avec une CODEOWNERS qui met l’équipe sécurité comme reviewer obligatoire.
- Chaque exception doit avoir un commentaire qui explique pourquoi, et une date d’expiration quand c’est possible.
Flux reconcilie, les PolicyReports vérifient que rien ne dérive.
Une politique de zéro exception n’est pas réaliste en production. Une politique d’exceptions traçables, approuvées et réexaminées régulièrement, oui.
Vérification d’images avec Sigstore v2 : la supply chain sous contrôle
Cosign v2 dans Kyverno, c’est la réponse concrète à XZ Utils et consorts.
XZ Utils début 2024, SolarWinds en 2020, la compromission de dépôts PyPI qui a duré des mois sans que personne ne le voie venir : la supply chain security n’est plus un sujet théorique. Ces incidents ont tous un point commun ; un attaquant patient qui a infiltré un pipeline de build légitime et signé des artefacts malveillants avec des clés valides. SLSA, SBOM, signatures d’images ; tout cet écosystème converge vers une question centrale : “comment savoir que l’image déployée est bien celle que les pipelines CI ont produite, et par qui ?”
Cosign v2 (du projet Sigstore) apporte deux modes de signature d’images. Le mode avec clé statique est le plus simple : les pipelines CI signent les images avec une clé privée, et Kyverno vérifie la signature avec la clé publique correspondante. C’est robuste mais nécessite de gérer des secrets de clés dans les pipelines.
Le mode keyless, plus moderne, repose sur une identité OIDC éphémère. Au moment de la signature, le pipeline CI obtient un token OIDC (via GitHub Actions OIDC, Google Workload Identity, etc.), présente ce token à Fulcio (la CA de Sigstore), et reçoit un certificat éphémère. La signature est réalisée avec ce certificat et enregistrée dans Rekor, le journal de transparence publique de Sigstore. Il n’y a plus de clé secrète à gérer : la preuve de signature est dans le journal public.
Kyverno v1.12+ gère les deux modes nativement via des règles VerifyImage. On peut exiger que toutes les images d’un namespace soient signées en mode keyless par une identité GitHub Actions spécifique (par exemple, un workflow précis d’un repository précis). Kyverno interroge Rekor, vérifie le certificat Fulcio, et autorise ou bloque l’admission.
En pratique, les équipes les plus matures combinent plusieurs contrôles : la signature d’image (avec Cosign), l’attestation SLSA (niveau 2 minimum), et la présence d’un SBOM attaché à l’image. Kyverno peut vérifier les trois via des règles VerifyImage distinctes sur le même Pod. Si l’une des trois vérifications échoue, le Pod n’est pas admis.
Sans vérification d’image à l’admission, la signature dans le pipeline CI ne sert à rien : un attaquant qui accède au cluster peut déployer n’importe quelle image. Kyverno ferme cette porte.
Chainsaw : tester ses policies comme du code applicatif
Chainsaw est le framework de test end-to-end développé par l’équipe Kyverno (anciennement basé sur kuttl). Il répond à un problème concret : comment valider qu’une policy fait bien ce qu’on attend avant de la déployer en production ?
Tester ses policies comme du code applicatif, c’est la seule façon de ne pas avoir peur de les modifier. Chainsaw permet d’écrire des scénarios de test déclaratifs : créer telle ressource, vérifier que la policy la bloque ou la mute de telle façon, vérifier que les PolicyReports contiennent les violations attendues. Ces scénarios tournent dans un cluster éphémère (kind ou un vrai cluster de CI) et produisent un résultat pass/fail.
Les policies sont du code. Elles ont des bugs, des régressions lors des mises à jour de Kyverno, des interactions non prévues quand on en ajoute une nouvelle à côté d’une autre. Les tester avec un framework dédié, une couverture, et une intégration CI, c’est la seule façon de maintenir une bibliothèque de policies sur le long terme sans avoir peur d’y toucher.
Une policy sans test est une policy qu’on a peur de modifier. Chainsaw retire cette peur.
Reports
Les PolicyReports et ClusterPolicyReports ont été réécrits en v2 et apportent une visibilité bien meilleure sur l’état de conformité du cluster. En v1, les reports étaient souvent incomplets ou en retard par rapport à l’état réel. En v2, la réconciliation en arrière-plan (background scan) est plus fiable : Kyverno réévalue périodiquement toutes les ressources existantes contre toutes les policies, même celles créées après les ressources.
Si on ajoute une nouvelle policy à un cluster existant, Kyverno va scanner toutes les ressources existantes et créer des violations dans les PolicyReports pour celles qui ne sont pas conformes ; et ce, même si ces ressources n’ont pas été modifiées récemment et n’ont donc pas déclenché l’admission webhook.
Policy Reporter + Grafana suffit pour 90% des besoins. Si vous avez un SIEM, les webhooks existent pour Splunk et Elastic ; mais commencez par Grafana, les dashboards de conformité sont prêts à l’emploi et montrent l’évolution dans le temps sans rien configurer.
Si votre organisation passe des audits ISO 27001 ou doit justifier sa conformité CIS Benchmark, les PolicyReports v2 sont une preuve automatisée et continue que vous pouvez exporter et présenter. Concrètement, ça remplace des heures de collecte manuelle par une requête kubectl.
ValidatingAdmissionPolicy vs Kyverno : quel choix ?
La ValidatingAdmissionPolicy est stable depuis Kubernetes 1.28. C’est une fonctionnalité native, sans composant externe à installer, qui utilise CEL pour exprimer des règles de validation. Son principal avantage, c’est d’être natif : pas de webhook externe, de composant supplémentaire à opérer, de dépendance à un projet tiers. Les règles VAP sont des ressources Kubernetes comme les autres, gérées par le même mécanisme que les CRD.
Mais VAP a des limites structurelles que Kyverno n’a pas. Elle ne peut que valider ; elle ne peut pas muter les ressources à l’admission, générer des ressources dérivées, ni vérifier des signatures d’images. Pour les équipes qui ont besoin de ces capacités, Kyverno reste indispensable.
| Critère | ValidatingAdmissionPolicy (VAP) | Kyverno | OPA/Gatekeeper |
|---|---|---|---|
| Langage de règles | CEL uniquement | YAML patterns + CEL | Rego |
| Validation | Oui | Oui | Oui |
| Mutation | Non | Oui | Non (partiel) |
| Génération de ressources | Non | Oui | Non |
| Vérification d’images | Non | Oui (Cosign/Sigstore) | Non |
| Composant externe | Non (natif) | Oui (admission webhook) | Oui (admission webhook) |
| Tests intégrés | Non | Oui (Chainsaw) | Oui (conftest) |
| PolicyReports | Non | Oui (v2) | Oui (via Gatekeeper Audit) |
| Courbe d’apprentissage | Faible (CEL) | Faible (YAML/CEL) | Élevée (Rego) |
| Maturité en prod | Moyenne | Élevée | Élevée |
Ma recommandation : VAP pour les validations simples où vous voulez éviter une dépendance externe, Kyverno dès que vous avez besoin de mutation, de génération de ressources ou de vérification de supply chain. Les deux coexistent sans friction sur le même cluster.
Ce n’est pas un compromis ; c’est la bonne architecture.
OPA/Gatekeeper et VAP : ce que Kyverno fait différemment
OPA/Gatekeeper reste la référence pour les équipes qui ont déjà investi dans Rego. Si une équipe a trois ans de policies Rego en production, la migration vers Kyverno ne se justifie pas pour des raisons purement techniques. Mais pour une nouvelle installation, la courbe d’apprentissage de Rego est un vrai frein que Kyverno élimine sans contrepartie notable.
VAP occupe une place différente : c’est la solution sans dépendance externe, native dans l’API Kubernetes depuis 1.28. Pour des validations simples, c’est souvent suffisant et l’argument opérationnel est légitime. La limite est structurelle : VAP ne mute pas, ne génère pas de ressources, et ne vérifie pas les signatures d’images. Ces trois capacités restent l’apanage de Kyverno.
Si vous démarrez un nouveau cluster en 2026 sans héritage Rego, installez Kyverno.
Il n’y a pas vraiment de débat. OPA/Gatekeeper est un très bon outil ; il n’est simplement pas le bon point d’entrée quand personne dans l’équipe ne connaît Rego, et que Kyverno couvre les mêmes cas en YAML que tout le monde sait déjà écrire.
- ✓ Kyverno 1.13/1.14 couvre l'ensemble du spectre de gouvernance Kubernetes : validation, mutation, génération de ressources et vérification de signatures d'images.
- ✓ L'API v2 (kyverno.io/v2) est la référence ; la migration depuis v1 est progressive et bien supportée par les outils.
- ✓ CEL est désormais utilisable dans Kyverno en complément des patterns YAML ; il offre une meilleure capacité d'expression pour les conditions complexes et de meilleures performances.
- ✓ Les PolicyExceptions stables permettent de gérer les cas particuliers de façon traçable et approuvée via GitOps, sans modifier les policies elles-mêmes.
- ✓ L'intégration Sigstore v2 permet de vérifier les signatures d'images à l'admission ; c'est un contrôle essentiel pour la supply chain security.
- ✓ Chainsaw permet de tester les policies comme du code applicatif ; une policy sans test est une policy fragile.
- ✓ ValidatingAdmissionPolicy native Kubernetes et Kyverno sont complémentaires, pas concurrents ; la stratégie hybride est recommandée pour les clusters Kubernetes 1.28+.
- ✓ OPA/Gatekeeper reste pertinent pour les équipes qui ont déjà investi dans Rego ; pour les nouvelles installations, Kyverno ou l'approche hybride Kyverno+VAP est souvent plus accessible.