VAP+MAP vs Kyverno vs Gatekeeper, Comparatif 2026

Trois approches dominent l'écosystème Kubernetes pour les policies d'admission : le duo natif ValidatingAdmissionPolicy + MutatingAdmissionPolicy (tous deux GA depuis 1.36), Kyverno et Gatekeeper. Ce comparatif présente leur état réel en avril 2026, y compris les transitions en cours qui changent la donne.

Ce que la CKS attend réellement

Le curriculum CKS évalue des objectifs sécurité (Pod Security Standards, registries autorisés, validation d'artefacts, SBOM, analyse statique), pas l'adhésion à un moteur de policy précis.

VAP, Kyverno et Gatekeeper sont des moyens possibles pour couvrir certaines attentes, mais aucun n'est cité comme compétence obligatoire. Ce comparatif est utile pour traduire les exigences CKS dans la vraie vie, pas comme sujet central de l'examen.

État des lieux 2026

Ce tableau synthétise les caractéristiques actuelles de chaque solution. Regardez d'abord les lignes "Installation" et "Langage principal" pour comprendre le positionnement : VAP+MAP sont natifs et utilisent CEL, Kyverno privilégie YAML avec CEL en complément, Gatekeeper s'appuie sur Rego (le langage d'OPA). La ligne "Positionnement 2026" résume les évolutions en cours.

Critère	VAP + MAP (natif)	Kyverno	Gatekeeper
Installation	Native, rien à déployer	Composant externe, ~40 s, 4 contrôleurs	Composant externe, ~2 min, 2 déploiements dont un à 3 répliques
Validation	GA depuis 1.30	Oui	Oui
Mutation	GA depuis 1.36 (MutatingAdmissionPolicy)	Oui	Oui
Génération	Non	Oui	Non
Vérification de signature d'image	Non	Oui (Cosign)	Non
Audit / reporting	Basique via Warn/Audit	PolicyReports	Intégré
Langage principal	CEL	YAML + CEL	Rego
Statut CNCF	Fonctionnalité native K8s	Incubating	Basé sur OPA (Graduated)
Positionnement 2026	Duo natif validation + mutation déclaratives	Moteur riche, transition CEL	OPA/Rego, génération de VAP si la policy est en CEL

Glissez pour voir

Les chiffres d'installation viennent d'un même cluster, dans la même session. Ils ne disent rien des performances en charge, mais ils disent quelque chose de l'empreinte : Kyverno déploie quatre contrôleurs distincts, admission, background, cleanup et reports, là où Gatekeeper en déploie deux mais porte son contrôleur à trois répliques par défaut. Aucun des deux n'est un composant d'appoint.

Trois précisions avant de lire ce tableau, parce qu'elles corrigent des raccourcis répandus. MutatingAdmissionPolicy est GA depuis Kubernetes 1.36 et activé par défaut, son MutatingAdmissionPolicyBinding compris ; vérifié sur le cluster de cette formation, kubectl api-resources --api-group=admissionregistration.k8s.io les liste bien en v1, et de portée cluster. Gatekeeper n'est pas un projet CNCF Graduated : c'est OPA, sur lequel il est construit, qui l'est. Et Kyverno 1.17, sorti en février 2026, pousse vers de nouveaux types de policy fondés sur CEL, le modèle historique ClusterPolicy étant en transition.

Transitions en cours (à ne pas ignorer)

Un comparatif de moteurs de règles vieillit vite, et 2026 est une année de bascule pour deux des trois. Les lire comme des produits figés conduirait à investir dans un modèle en cours de dépréciation, ou à opposer deux solutions qui apprennent justement à cohabiter.

Kyverno 1.17 : migration CEL

Kyverno 1.17 introduit quatre nouveaux types de policy fondés sur CEL, ValidatingPolicy, MutatingPolicy, GeneratingPolicy et ImageValidatingPolicy, avec un guide de migration officiel depuis les ClusterPolicy historiques. Si vous investissez dans Kyverno aujourd'hui, anticipez cette bascule : l'ancien modèle reste supporté, mais il est déprécié, et écrire de nouvelles policies dessus revient à créer de la dette le jour même.

Gatekeeper : la génération de VAP a une condition

Elle est décisive et rarement mentionnée : Gatekeeper ne génère une VAP que depuis un ConstraintTemplate écrit en CEL, c'est-à-dire déclarant un bloc code avec engine: K8sNativeValidation. Vérifié sur la version 3.23.1, un template en Rego ne produit aucune VAP, et l'application passe alors entièrement par le webhook.

Comme la quasi-totalité des bibliothèques de policies publiques sont écrites en Rego, le chemin natif ne s'ouvre qu'au prix d'une réécriture. C'est ce qui sépare une convergence annoncée d'une convergence effective.

Quand la condition est remplie, la génération se fait en deux temps mesurables : la VAP en deux secondes, son binding en trente, ce dernier délai étant réglé par --default-wait-for-vapb-generation. Pendant cet intervalle la VAP existe sans binding, donc n'applique rien, et c'est encore le webhook qui refuse.

Gatekeeper 3.22 : intégration VAP

Depuis Gatekeeper 3.22, le flag sync-vap-enforcement-scope vaut true par défaut : Gatekeeper sait désormais générer des ressources VAP à partir de ses propres critères. La conséquence change la façon de poser le choix. « VAP ou Gatekeeper » n'est plus une alternative tranchée : Gatekeeper peut cohabiter avec le mécanisme natif, en s'appuyant dessus plutôt qu'en le doublant.

Comparaison détaillée

Le tableau précédent donne les caractéristiques ; cette section montre ce que chaque solution donne à écrire. C'est le critère le plus concret, parce que c'est celui que vos équipes vivront tous les jours : la même règle, interdire les conteneurs privilégiés, exprimée dans les trois langages.

Langage de policy

Les trois onglets ci-dessous expriment exactement la même règle. Comparez-les sur leur lisibilité pour quelqu'un qui n'a pas écrit la policy, pas sur leur concision : une règle de sécurité est relue bien plus souvent qu'elle n'est écrite.

VAP (CEL)

spec:
  validations:
    - expression: |
        !object.spec.containers.exists(c,
          has(c.securityContext) &&
          has(c.securityContext.privileged) &&
          c.securityContext.privileged
        )
      message: "Conteneurs privilégiés interdits"

Avantages :

• Expressif et typé
• Standard Kubernetes (utilisé dans CRD validation)
• Exécution in-process (pas de webhook)

Inconvénients :

• Syntaxe moins intuitive que YAML
• Nécessite des has() pour éviter les erreurs sur champs absents

Kyverno (YAML/CEL)

# Syntaxe 1.17+ (CEL)
spec:
  rules:
    - name: deny-privileged
      validate:
        failureAction: Deny
        cel:
          expressions:
            - expression: |
                !object.spec.containers.exists(c,
                  c.securityContext.privileged == true
                )

Avantages :

• Syntaxe YAML native, intuitive (modèle historique)
• CEL pour les cas complexes (modèle 1.17+)
• Documentation excellente

Inconvénients :

• Modèle historique en transition
• Complexité opérationnelle (webhook, HA)

Gatekeeper (Rego)

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  container.securityContext.privileged == true
  msg := sprintf("Conteneur '%v' privileged", [container.name])
}

Avantages :

• Le plus puissant des trois
• Réutilisable hors Kubernetes (Terraform, APIs)
• Références croisées, calculs complexes

Inconvénients :

• Courbe d'apprentissage significative
• Debugging plus difficile

Modèle d'application

Engine	Modèle	Commentaire
VAP	Policy + Binding + Params (3 ressources)	Séparation claire : logique / scope / valeurs
Kyverno	ClusterPolicy (1 ressource) ou nouveaux types CEL	Tout-en-un historique, transition vers types dédiés
Gatekeeper	Template + Constraint (2 ressources)	Template Rego réutilisable, Constraint l'instancie

Glissez pour voir

Les modèles VAP et Gatekeeper facilitent la séparation des responsabilités : l'équipe plateforme crée les templates/policies, les équipes applicatives les instancient.

Fonctionnalités

Chaque engine couvre un périmètre différent. La validation est disponible partout, mais les différences apparaissent sur la mutation (modifier les objets avant leur création), la génération (créer automatiquement d'autres ressources), et la vérification d'images (Cosign/Sigstore). Si vous avez besoin de génération ou de signature d'images, Kyverno est actuellement le seul à proposer ces fonctionnalités.

Fonctionnalité	VAP + MAP	Kyverno	Gatekeeper
Validation	GA	Oui	Oui
Mutation	GA en 1.36 (MAP)	Mature	Stable
Génération	Non	Unique	Non
Image verification	Non	Cosign/Sigstore	Non
Paramétrage	paramRef/paramKind	Variables	Via Constraint
Déploiement progressif	Warn/Audit via validationActions	Audit mode	dryrun/warn
matchConditions	CEL	YAML/CEL	Rego

Glissez pour voir

Une idée reçue à écarter : VAP dispose bien d'un mécanisme de déploiement progressif. Le champ validationActions du binding accepte Warn, qui alerte sans bloquer, et Audit, qui enregistre. On peut donc observer l'effet d'une policy sur le trafic réel avant de la passer en refus, exactement comme avec un moteur externe.

Performances

Approche qualitative (pas de benchmark officiel robuste disponible) :

Engine	Caractéristique	Impact
VAP	Exécution in-process dans l'API server	Latence la plus faible, pas d'appel réseau
Kyverno	Webhook HTTP externe	Coût réseau + composant externe
Gatekeeper	Webhook HTTP externe + Rego	Coût réseau + évaluation Rego

Glissez pour voir

Conclusion : VAP est structurellement le plus performant pour la validation pure. Pour la plupart des clusters, les trois solutions sont suffisamment performantes, mais sur des clusters à fort volume, VAP a un avantage architectural.

Écosystème

Au-delà des fonctionnalités techniques, l'écosystème influence fortement votre productivité. Une librairie de policies prêtes à l'emploi évite de tout écrire soi-même. Une CLI dédiée facilite les tests avant déploiement. L'intégration GitOps garantit un workflow déclaratif cohérent avec ArgoCD ou Flux.

Aspect	VAP	Kyverno	Gatekeeper
Librairie de policies	À écrire soi-même	Policy Library (200+)	Gatekeeper Library
CLI pour tests	kubectl	kyverno CLI	gator (recommandé) / opa
ArgoCD/Flux	Natif	Intégration forte	Intégration
Community	SIG Auth	CNCF Incubating	Basé sur OPA (CNCF Graduated)

Glissez pour voir

Scénarios de choix

Aucune des trois solutions n'est meilleure dans l'absolu, et le tableau de comparaison ne tranche pas tout seul. Les trois scénarios ci-dessous partent du contexte plutôt que des fonctionnalités : c'est lui qui décide.

Choisir VAP + MAP si...

✅ Kubernetes 1.36+ (mutation et validation natives) ou 1.30+ (validation seule) ✅ Performance critique (validations à haute fréquence) ✅ Architecture minimaliste sans composant externe ✅ Équipe à l'aise avec CEL ✅ Mutations simples (label par défaut, runAsNonRoot: true, valeurs par défaut)

Limites à connaître :

• Pas de génération d'autres ressources (NetworkPolicy, Secret, ConfigMap auto-créés)
• Pas de vérification de signature d'image (Cosign)
• Pas de librairie prête à l'emploi
• Pas de reporting riche comme PolicyReports

Recommandation CKS : le duo VAP + MAP est le choix le plus aligné avec l'approche "native Kubernetes" attendue à l'examen.

Choisir Kyverno si...

✅ Besoins de mutation importants (injection de sidecars, defaults) ✅ Génération automatique de ressources (NetworkPolicies, Secrets) ✅ Vérification d'images (Cosign/Sigstore) ✅ Équipe préférant YAML pur

Attention en 2026 :

• Le modèle historique ClusterPolicy est en transition vers les nouveaux types CEL
• Investir massivement dans l'ancien modèle peut créer une dette technique
• Complexité opérationnelle (webhook, HA, debugging)

Choisir Gatekeeper si...

Gatekeeper garde un terrain propre, et il tient à son écosystème plus qu'à ses fonctionnalités :

✅ OPA déjà utilisé ailleurs (Terraform, CI, APIs) ✅ Équipe maîtrisant Rego ✅ Policies complexes avec références croisées ✅ Besoin d'audit intégré des ressources existantes

Évolution 2026 :

• Gatekeeper s'intègre mieux avec VAP (génération de ressources VAP)
• Coût cognitif et opérationnel plus élevé qu'un VAP natif
• Reste le choix OPA/Rego pour les équipes investies dans cet écosystème

Combinaisons possibles

Rien n'empêche de combiner plusieurs engines pour bénéficier de leurs forces respectives. L'approche la plus courante consiste à utiliser VAP pour les validations critiques (performance) et Kyverno ou Gatekeeper pour les fonctionnalités avancées (mutation, génération, audit). Ce tableau présente les combinaisons les plus pertinentes, mais attention aux risques documentés dans l'encadré qui suit.

Combinaison	Use case	Avantage
VAP + Kyverno	VAP pour validation critique, Kyverno pour mutation/génération	Performance + fonctionnalités complètes
VAP + Gatekeeper audit	VAP enforce, Gatekeeper pour conformité continue	Performance + audit détaillé
Kyverno seul	Couverture complète sans Rego	Simplicité conceptuelle (attention transition 1.17)

Glissez pour voir

Chaque moteur ajouté multiplie les points de rejet à l'admission, et la facture se paie en exploitation. Le diagnostic devient plus difficile, puisqu'il faut d'abord déterminer qui a rejeté. Les règles se dupliquent d'un moteur à l'autre sans que personne ne s'en aperçoive. Des effets d'ordre apparaissent entre webhooks et mécanismes natifs. Et la charge cognitive de l'équipe augmente d'autant. N'ajoutez donc un moteur que s'il apporte une capacité réellement manquante, pas par confort.

Migration vers VAP + MAP

Avec VAP en GA depuis 1.30 et MAP en GA depuis 1.36, migrer les validations et les mutations simples depuis Kyverno/Gatekeeper vers le duo natif devient pertinent.

Ce qui se migre bien

Une migration vers VAP réussit sur les règles qui se formulent comme une condition sur l'objet soumis, sans rien avoir besoin d'autre :

• Interdire les conteneurs privilégiés (VAP)
• Restreindre les registries autorisés (VAP)
• Exiger certains labels (VAP)
• Bloquer hostPath, hostNetwork (VAP)
• Limiter les réplicas (VAP)
• Injecter un label par défaut (MAP ApplyConfiguration)
• Imposer runAsNonRoot: true ou allowPrivilegeEscalation: false par défaut (MAP)
• Ajouter des annotations standards (MAP)

Ce qui ne se migre PAS simplement

Les règles qui résistent ont toutes un point commun : elles ont besoin de quelque chose que VAP ne fournit pas, un appel extérieur, un autre objet du cluster, ou la création d'une ressource.

• Génération : ni VAP ni MAP ne génèrent d'autres ressources (Kyverno reste seul)
• Vérification d'images : pas d'équivalent Cosign en natif
• Policies complexes : certaines logiques Rego ne se traduisent pas en CEL
• Mutation par référence croisée (lire un ConfigMap, fusionner avec un secret) : limité en CEL

Exemple de conversion

Kyverno CEL

spec:
  rules:
    - name: deny-privileged
      validate:
        cel:
          expressions:
            - expression: |
                !object.spec.containers.exists(c,
                  c.securityContext.privileged == true
                )

VAP équivalent

spec:
  validations:
    - expression: |
        !object.spec.containers.exists(c,
          has(c.securityContext) &&
          has(c.securityContext.privileged) &&
          c.securityContext.privileged
        )

Différence principale : VAP nécessite des has() pour vérifier l'existence des champs avant d'y accéder.

Tableau de décision

Comment utiliser ce tableau : Parcourez les questions de haut en bas. Dès qu'une réponse correspond à votre situation, la recommandation associée est probablement le bon choix. Si plusieurs lignes correspondent, privilégiez celle qui répond au besoin le plus critique pour votre contexte.

Question	Réponse	Recommandation	Pourquoi
Kubernetes 1.30+ ?	Non	Kyverno ou Gatekeeper	VAP non disponible
Validation simple uniquement ?	Oui	VAP	Natif, performant, sans dépendance
Mutation simple (label, default) sur K8s 1.36+ ?	Oui	MAP	Natif, sans webhook
Mutation avec génération d'autres ressources ?	Oui	Kyverno	Seul à proposer la génération
Signature d'images ?	Oui	Kyverno	Intégration Cosign native
OPA/Rego déjà utilisé ?	Oui	Gatekeeper	Réutilisation des compétences
Policies très complexes ?	Oui	Gatekeeper	Rego le plus puissant
Architecture minimaliste ?	Oui	VAP + MAP	Pas de composant externe

Glissez pour voir

Ce que la CKS attend réellement

Pour clarifier le positionnement de ce comparatif par rapport à l'examen :

La certification CKS évalue votre capacité à sécuriser un cluster, pas votre maîtrise d'un outil spécifique. Le tableau ci-dessous montre comment les différents policy engines peuvent répondre aux objectifs du curriculum, mais l'examinateur s'intéresse au résultat ("les Pods ne peuvent pas être privilégiés"), pas à l'outil utilisé pour y parvenir.

Domaine CKS	Ce qui est évalué	Outil possible
Cluster Hardening	Pod Security Standards, restrictions	VAP, PSA, Kyverno, Gatekeeper
Supply Chain Security	Registries autorisées, signatures, SBOM	Kyverno (Cosign), Gatekeeper, outils externes
System Hardening	Least privilege, seccomp, AppArmor	Tous peuvent contribuer
Minimize Microservice Vulnerabilities	Network policies, secrets	Kyverno (génération), VAP

Glissez pour voir

L'examen évalue des résultats sécurité, pas la maîtrise d'un outil spécifique. Vous devez savoir implémenter des contrôles, pas nécessairement avec Kyverno ou Gatekeeper.

À retenir

1. VAP + MAP (GA 1.30 / GA 1.36) : duo natif validation + mutation, sans webhook, le plus aligné CKS
2. Kyverno : mutation/génération/signatures, mais transition 1.17 à anticiper
3. Gatekeeper : OPA/Rego + audit intégré, intégration VAP renforcée en 3.22
4. Combinaison possible : VAP+MAP pour validation et mutation simple + Kyverno pour génération/signatures, mais attention aux risques
5. CKS : évalue des objectifs sécurité, pas un outil spécifique

Contrôle de connaissances

Sept questions sur ce qui décide vraiment entre ces trois moteurs, et sur les deux transitions de 2026 qui changent la donne.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Pour aller plus loin

• Supply Chain Security : Le cas d'usage qui départage le mieux les trois moteurs, la vérification de signature.
• Image Scanning : Les données de vulnérabilité qu'une policy d'admission peut exiger avant de laisser passer un Pod.
• Audit Logs : La trace des décisions d'admission, indispensable pour prouver qu'une policy s'applique.

×

📖 Voir la documentation →