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 (webhook)	Composant externe (webhook)
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, intégration VAP renforcée

Glissez pour voir

Précisions importantes

• MutatingAdmissionPolicy est passé GA en Kubernetes 1.36 et activé par défaut. Le pendant MutatingAdmissionPolicyBinding également. Vérifiable sur un cluster 1.36 avec kubectl api-resources --api-group=admissionregistration.k8s.io, qui liste bien les MAP en v1.
• Gatekeeper est construit autour d'OPA — c'est OPA qui est CNCF Graduated, pas Gatekeeper en tant que projet distinct.
• Kyverno 1.17 (février 2026) pousse la migration vers les nouveaux policy types CEL, le modèle historique ClusterPolicy est en transition.

Transitions en cours (à ne pas ignorer)

Kyverno 1.17 : migration CEL

Kyverno en transition

Kyverno 1.17 introduit des nouveaux policy types basés sur CEL (ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy) et fournit un guide officiel de migration depuis les ClusterPolicy historiques.

Si vous investissez dans Kyverno aujourd'hui, anticipez cette transition. L'ancien modèle reste supporté mais est deprecated.

Gatekeeper 3.22 : intégration VAP

Gatekeeper + VAP

Depuis Gatekeeper 3.22, le flag sync-vap-enforcement-scope passe par défaut à true. Gatekeeper peut désormais générer des ressources VAP à partir de ses critères d'enforcement.

La frontière "VAP vs Gatekeeper" devient moins binaire : Gatekeeper peut cohabiter avec le mécanisme natif plutôt que de le remplacer entièrement.

Comparaison détaillée

Langage de policy

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

VAP et déploiement progressif

Contrairement à une idée reçue, VAP dispose bien d'un mécanisme de déploiement progressif via validationActions dans le binding : Warn (alerte sans bloquer) et Audit (enregistrement).

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

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...

✅ 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

Risques des combinaisons

Plus vous combinez d'engines, plus vous multipliez les points de rejet à l'admission :

• Debugging plus difficile (quel webhook a rejeté ?)
• Risque de règles redondantes
• Effets d'ordre entre webhooks et mécanismes natifs
• Charge cognitive pour les équipes

N'ajoutez un engine que s'il apporte une capacité vraiment manquante.

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

• 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

• 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

Prochaines étapes

ValidatingAdmissionPolicy (CKS) Guide complet VAP — approche recommandée CKS

Kyverno Guide complet Kyverno avec transition 1.17

Gatekeeper Guide complet OPA/Gatekeeper

Pod Security Standards Policies de base Kubernetes

×

📖 Voir la documentation →