ValidatingAdmissionPolicy & MutatingAdmissionPolicy, Policies natives en CEL (CKS)

ValidatingAdmissionPolicy (VAP) est la solution native Kubernetes pour valider les ressources à l'admission sans webhook externe. Ce guide est orienté préparation CKS : il vous apprend à utiliser VAP, mais surtout à choisir le bon mécanisme (VAP, PSA, RBAC, webhook) et à diagnostiquer rapidement un refus.

Ce que vous allez apprendre

Choisir entre VAP, Pod Security Admission, RBAC et webhooks
Créer des policies pour securityContext, hostPath et registries
Diagnostiquer rapidement un refus d'admission
Connaître les limites de VAP pour l'examen

Versions et disponibilité

VAP a atteint la maturité GA (General Availability) dans Kubernetes 1.30, ce qui signifie qu'il est stable et supporté pour la production. Depuis Kubernetes 1.36 (avril 2026), son pendant MutatingAdmissionPolicy est lui aussi GA et activé par défaut : Kubernetes dispose désormais d'un duo natif complet validation + mutation, sans webhook externe.

Feature	Version	État	Notes CKS
ValidatingAdmissionPolicy	1.30+	GA	Utilisable à l'examen
MutatingAdmissionPolicy	1.36+	GA, activée par défaut	Disponible nativement

Quand utiliser VAP vs les alternatives

Question clé pour la CKS : quel mécanisme pour quel besoin ?

Kubernetes offre plusieurs mécanismes de contrôle. La confusion entre eux est fréquente, même chez les professionnels expérimentés. Ce tableau vous aide à choisir le bon outil selon votre objectif.

Besoin	Mécanisme recommandé	Pourquoi
Forcer runAsNonRoot, drop capabilities	Pod Security Admission	Conçu pour ça, 3 profils prêts à l'emploi
Empêcher un user de créer des Secrets	RBAC	Contrôle d'accès par identité
Bloquer hostPath ou registries non autorisées	VAP	Validation de contenu, pas d'identité
Injecter un label par défaut, ajouter `runAsNonRoot: true`	MutatingAdmissionPolicy (GA en 1.36)	Mutation déclarative en CEL, sans webhook
Muter avec génération d'autres ressources (NetworkPolicy, Secret)	Kyverno	Seul à proposer la génération
Exiger une signature d'image	ImagePolicyWebhook / Kyverno	VAP ne vérifie pas les signatures
Logique métier complexe	Webhook externe	Plus de flexibilité que CEL

Règle pratique : Si le contrôle porte sur l'identité (qui fait l'action), c'est RBAC. Si le contrôle porte sur le contenu (ce qui est créé), c'est VAP ou PSA.

Ce que VAP ne remplace PAS

VAP intervient à un moment précis de la chaîne d'admission : après l'authentification et l'autorisation RBAC, sur le contenu de l'objet soumis. Tout ce qui se joue avant (qui parle) ou après (ce qui circule sur le réseau, ce qui est signé) lui échappe par construction. La liste ci-dessous n'est donc pas un inventaire de manques à combler : ce sont des couches complémentaires qui doivent coexister.

RBAC : VAP ne contrôle pas qui peut faire quoi, seulement quoi est créé
Pod Security Admission : pour les baselines de sécurité standard, PSA est plus simple
NetworkPolicy : VAP ne filtre pas le trafic réseau
Signature d'artefacts : VAP ne vérifie pas les signatures cosign/notation
Audit avancé : VAP ne génère pas de rapports de conformité détaillés

Architecture VAP

Une policy VAP se compose de trois ressources, et cette séparation est ce qui déroute au premier contact. La ValidatingAdmissionPolicy porte la logique en CEL mais ne s'applique à rien tant qu'elle est seule : déclarée sans binding, elle est inerte, c'est le piège le plus fréquent. Le ValidatingAdmissionPolicyBinding décide où et comment elle agit (quels namespaces, en mode Audit, Warn ou Deny). La ressource de paramètres, optionnelle, est un ConfigMap ou une CRD qui rend la même logique réutilisable avec des valeurs différentes.

Architecture VAP : Policy, Binding et ConfigMap

Retenez la conséquence pratique : une policy et son binding sont deux objets kubectl apply distincts, et vous devez vérifier les deux quand une règle « ne fait rien ».

Pourquoi VAP plutôt qu'un webhook externe ?

Avant VAP, pour valider des ressources au-delà de ce que PSA permet, il fallait déployer un webhook externe (Kyverno, Gatekeeper, ou un webhook maison). Cela implique de maintenir un composant supplémentaire, de gérer ses certificats TLS, et de surveiller sa disponibilité.

VAP élimine cette complexité opérationnelle pour les cas de validation simples.

Aspect	VAP + MAP (natifs)	Webhooks (Kyverno, Gatekeeper)
Installation	Rien à installer	Déploiement requis
Performance	In-process, très rapide	Appel réseau
Disponibilité	Pas de dépendance réseau externe	SPOF si mal configuré
Langage	CEL uniquement	YAML, Rego, CEL
Mutation	GA en 1.36 (MutatingAdmissionPolicy)	Stable et mature
Audit	`validationActions: [Audit]`	Rapports détaillés

Quand choisir un webhook malgré tout ? Si vous avez besoin de génération de ressources (Kyverno crée des NetworkPolicies à partir d'un template) ou de rapports de conformité détaillés (PolicyReports), les webhooks restent nécessaires. La mutation simple (ajout de labels, valeurs par défaut) bascule désormais en natif via MutatingAdmissionPolicy.

Exemple 1 : Imposer un securityContext sécurisé

Cet exemple est directement aligné avec l'objectif CKS "Use appropriate pod security standards" du domaine Minimize Microservice Vulnerabilities. Il impose plusieurs contraintes de sécurité :

runAsNonRoot: true
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-secure-securitycontext
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    # Tous les conteneurs doivent avoir runAsNonRoot
    - expression: |
        object.spec.containers.all(c,
          has(c.securityContext) &&
          has(c.securityContext.runAsNonRoot) &&
          c.securityContext.runAsNonRoot == true
        )
      message: "Tous les conteneurs doivent avoir runAsNonRoot: true"
      reason: Forbidden

    # Interdire allowPrivilegeEscalation
    - expression: |
        object.spec.containers.all(c,
          !has(c.securityContext) ||
          !has(c.securityContext.allowPrivilegeEscalation) ||
          c.securityContext.allowPrivilegeEscalation == false
        )
      message: "allowPrivilegeEscalation doit être false"
      reason: Forbidden

    # Exiger readOnlyRootFilesystem
    - expression: |
        object.spec.containers.all(c,
          has(c.securityContext) &&
          has(c.securityContext.readOnlyRootFilesystem) &&
          c.securityContext.readOnlyRootFilesystem == true
        )
      message: "readOnlyRootFilesystem doit être true"
      reason: Forbidden

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: require-secure-securitycontext-binding
spec:
  policyName: require-secure-securitycontext
  validationActions: [Deny]
  matchResources:
    namespaceSelector:
      matchLabels:
        security: strict

# Créer le namespace avec le label
kubectl create namespace secure-ns
kubectl label namespace secure-ns security=strict

# Appliquer la policy et le binding
kubectl apply -f secure-securitycontext-policy.yaml
kubectl apply -f secure-securitycontext-binding.yaml

# Test ÉCHEC : pod sans runAsNonRoot
kubectl run bad-pod --image=nginx -n secure-ns

# Test SUCCÈS : pod avec securityContext complet
kubectl run good-pod --image=nginx -n secure-ns \
  --overrides='{
    "spec": {
      "containers": [{
        "name": "nginx",
        "image": "nginx",
        "securityContext": {
          "runAsNonRoot": true,
          "runAsUser": 1000,
          "allowPrivilegeEscalation": false,
          "readOnlyRootFilesystem": true
        }
      }]
    }
  }'

Exemple 2 : Refuser les volumes hostPath

Les volumes hostPath sont un vecteur d'attaque classique : ils permettent d'accéder au filesystem de l'hôte. Cette policy les interdit :

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: deny-hostpath-volumes
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: |
        !has(object.spec.volumes) ||
        !object.spec.volumes.exists(v, has(v.hostPath))
      message: "Les volumes hostPath sont interdits"
      reason: Forbidden

Test :

# Doit échouer
kubectl run hostpath-pod --image=nginx -n secure-ns \
  --overrides='{
    "spec": {
      "volumes": [{"name": "host-vol", "hostPath": {"path": "/etc"}}],
      "containers": [{
        "name": "nginx",
        "image": "nginx",
        "volumeMounts": [{"name": "host-vol", "mountPath": "/host-etc"}],
        "securityContext": {"runAsNonRoot": true, "runAsUser": 1000, "allowPrivilegeEscalation": false, "readOnlyRootFilesystem": true}
      }]
    }
  }'

Exemple 3 : Limiter les registries autorisées (Supply Chain)

Cet exemple introduit le troisième composant de l'architecture : le paramétrage. La liste des registres autorisés ne vit pas dans la policy mais dans un ConfigMap, désigné par le paramRef du binding et lu en CEL via params. L'intérêt est direct : ajouter un registre se fait par un kubectl edit configmap, sans toucher à la logique de validation ni la redéployer. Notez le parameterNotFoundAction: Deny du binding, qui décide du comportement si le ConfigMap disparaît : refuser par défaut est le seul choix défendable sur une règle de sécurité, l'alternative laisserait tout passer silencieusement.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: restrict-image-registries
spec:
  failurePolicy: Fail
  paramKind:
    apiVersion: v1
    kind: ConfigMap
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  variables:
    - name: allowedRegistries
      expression: |
        params.data.allowedRegistries.split(',')
  validations:
    - expression: |
        object.spec.containers.all(c,
          variables.allowedRegistries.exists(r, c.image.startsWith(r))
        )
      messageExpression: |
        'Image non autorisée. Registries autorisés: ' + params.data.allowedRegistries
      reason: Forbidden

apiVersion: v1
kind: ConfigMap
metadata:
  name: allowed-registries
  namespace: secure-ns
data:
  allowedRegistries: "gcr.io/my-project,docker.io/library"

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: restrict-registries-binding
spec:
  policyName: restrict-image-registries
  validationActions: [Deny]
  paramRef:
    name: allowed-registries
    namespace: secure-ns
    parameterNotFoundAction: Deny
  matchResources:
    namespaceSelector:
      matchLabels:
        security: strict

Mutation native avec MutatingAdmissionPolicy (GA 1.36)

Depuis Kubernetes 1.36, vous pouvez muter des ressources avec la même approche déclarative que VAP, mais via une MutatingAdmissionPolicy (MAP). Le pattern à retenir : VAP valide, MAP modifie, les deux s'écrivent en CEL et s'appliquent via un Binding.

Les mutations supportent deux patchType :

ApplyConfiguration, décrit l'objet partiel à fusionner via Server-Side Apply. Lisible, robuste sur les champs structurés.
JSONPatch, liste d'opérations JSON Patch (RFC 6902). Plus expressif mais plus fragile sur les chemins absents.

Exemple : injecter un label par défaut

Cet exemple ajoute automatiquement le label team: platform à tout pod créé dans le namespace map-test. Pratique pour appliquer des conventions sans dépendre des développeurs.

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: add-team-label
spec:
  failurePolicy: Fail
  reinvocationPolicy: Never
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
  matchConditions:
    - name: only-test-namespace
      expression: "request.namespace == 'map-test'"
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: |
          Object{
            metadata: Object.metadata{
              labels: {"team": "platform"}
            }
          }

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicyBinding
metadata:
  name: add-team-label-binding
spec:
  policyName: add-team-label
  matchResources:
    namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: map-test

# Créer le namespace ciblé
kubectl create namespace map-test

# Appliquer la policy + le binding
kubectl apply -f add-team-label-policy.yaml
kubectl apply -f add-team-label-binding.yaml

# Lancer un pod sans label "team"
kubectl -n map-test run nginx --image=nginx:alpine --restart=Never

# Vérifier que MAP a injecté team=platform
kubectl -n map-test get pod nginx -o jsonpath='{.metadata.labels}'
# {"run":"nginx","team":"platform"}

Quand préférer MAP plutôt qu'un webhook Kyverno ?

Le tableau se lit par ses deux lignes du milieu, qui portent toute la décision. Sur une mutation simple, les deux outils font la même chose et le natif gagne par élimination du composant à exploiter. Dès que le besoin devient génération ou vérification de signature, MAP ne peut pas répondre, la question ne se pose plus.

Critère	MAP (natif)	Kyverno mutation
Installation	Rien à déployer	Déploiement requis (HA, certificats)
Mutation simple (label, default)	Idéal	Idéal
Génération de ressources	Non	Oui (NetworkPolicy, Secret, ConfigMap)
Vérification d'images	Non	Oui (Cosign/Sigstore)
Langage	CEL	YAML + CEL

MAP couvre les mutations « valeurs par défaut » et « ajout de label ». Kyverno reste nécessaire pour la génération d'autres objets ou la vérification de signature d'images.

Variables CEL disponibles

Lorsque vous écrivez une expression CEL dans une policy VAP, vous avez accès à plusieurs variables injectées automatiquement par Kubernetes. Comprendre ces variables est essentiel pour écrire des expressions efficaces.

Variable	Description	Usage principal
`object`	Ressource entrante (CREATE/UPDATE)	Valider les champs
`oldObject`	Ressource existante (UPDATE uniquement)	Empêcher certaines modifications
`request`	Métadonnées (user, operation, namespace)	Règles conditionnelles
`params`	Paramètres de la policy (ConfigMap/CRD)	Rendre configurable
`namespaceObject`	Le namespace de la ressource	Vérifier labels du namespace

Exemple pratique :

object.spec.containers : accéder aux conteneurs du pod entrant
oldObject.metadata.labels : comparer avec les labels actuels lors d'un UPDATE
request.userInfo.username : connaître qui fait la requête
params.data.maxReplicas : lire une valeur du ConfigMap paramétrique

Expressions CEL courantes pour la CKS

Ces expressions couvrent l'essentiel de ce qu'on demande en épreuve pratique. Trois fonctions reviennent en permanence et il faut savoir laquelle choisir : all() vérifie que tous les éléments respectent une condition (utile pour imposer), exists() qu'au moins un la respecte (utile pour interdire, en préfixant d'un !), et has() teste la présence d'un champ avant d'y accéder. Le réflexe à ancrer : has() ne protège que d'un niveau. Écrire has(c.securityContext.runAsNonRoot) sur un conteneur dépourvu de securityContext déclenche une erreur d'évaluation, et avec failurePolicy: Fail la requête est refusée avec un message illisible qui recopie l'expression entière. D'où le double has() dans les exemples.

# Exiger runAsNonRoot
object.spec.containers.all(c,
  has(c.securityContext) &&
  has(c.securityContext.runAsNonRoot) &&
  c.securityContext.runAsNonRoot == true
)

# Refuser privileged (le premier has() évite l'erreur si securityContext est absent)
!object.spec.containers.exists(c,
  has(c.securityContext) &&
  has(c.securityContext.privileged) &&
  c.securityContext.privileged == true
)

# Refuser hostPath (le has() couvre le cas d'un pod sans volume)
!has(object.spec.volumes) ||
!object.spec.volumes.exists(v, has(v.hostPath))

# Refuser hostNetwork/hostPID/hostIPC
!object.spec.hostNetwork &&
!object.spec.hostPID &&
!object.spec.hostIPC

# Vérifier préfixe d'image
object.spec.containers.all(c, c.image.startsWith('gcr.io/'))

# Exclure les namespaces système
!request.namespace.startsWith("kube-")

Actions de validation et déploiement progressif

Une erreur courante est de déployer une policy directement en mode Deny et de casser la production. Les actions de validation permettent un déploiement progressif et sécurisé.

Action	Effet	Phase
`Audit`	Log seulement, accepte la requête	Découverte
`Warn`	Accepte + warning visible dans kubectl	Transition
`Deny`	Refuse la requête	Production

Pourquoi cette progression ?

Audit : Vous déployez la policy sans impact. Les violations sont loggées, vous découvrez quelles ressources existantes ne seraient pas conformes.
Warn : Les développeurs voient les warnings lors de leurs déploiements. Ils ont le temps de corriger avant le blocage.
Deny : Une fois tous les workloads conformes, vous activez le blocage.

Stratégie recommandée :

# Étape 1 : Observer (pas d'impact)
validationActions: [Audit]

# Étape 2 : Alerter (les users voient les warnings)
validationActions: [Warn, Audit]

# Étape 3 : Bloquer
validationActions: [Deny]

Troubleshooting rapide (réflexes CKS)

Commandes de diagnostic

Ces cinq commandes se lancent dans l'ordre et éliminent une hypothèse chacune : la policy existe-t-elle, son expression compile-t-elle, le refus a-t-il laissé une trace, que voit exactement le client, le namespace porte-t-il le label attendu par le binding. La troisième mérite un avertissement : un refus VAP sur une création directe (kubectl run, kubectl apply) ne produit aucun Event, l'erreur est simplement renvoyée à l'appelant. Vous ne verrez des Events que lorsqu'un contrôleur retente la création, typiquement un ReplicaSet qui remonte des FailedCreate contenant le nom de la policy.

# 1. Lister toutes les policies et bindings
kubectl get validatingadmissionpolicies,validatingadmissionpolicybindings

# 2. Voir les détails d'une policy (erreurs de type-checking)
kubectl describe validatingadmissionpolicy <name>

# 3. Voir les events récents (uniquement si un contrôleur retente la création)
kubectl get events -A --sort-by=.lastTimestamp | grep -i admission

# 4. Tester un manifest avec verbosité
kubectl apply -f pod.yaml --v=8

# 5. Vérifier si le namespace a les bons labels
kubectl get namespace <ns> --show-labels

D'où vient le refus ?

Un refus à la création peut venir de plusieurs sources. C'est une source fréquente de confusion : vous pensiez que VAP bloquait, mais c'était PSA. Ou l'inverse. Voici comment identifier la source exacte.

Source	Comment vérifier	Message typique
ValidatingAdmissionPolicy	`kubectl get validatingadmissionpolicies`	`ValidatingAdmissionPolicy 'xxx' with binding 'yyy' denied request`
Pod Security Admission	Label `pod-security.kubernetes.io/*`	`violates PodSecurity "restricted"`
ResourceQuota	`kubectl describe quota`	`exceeded quota`
LimitRange	`kubectl describe limitrange`	`must be less than or equal to`
RBAC	`kubectl auth can-i`	`forbidden: User "x" cannot create`
Webhook externe	`kubectl get validatingwebhookconfigurations`	`admission webhook "xxx" denied`

Astuce de diagnostic rapide : Le message d'erreur contient généralement le nom du mécanisme qui bloque. Lisez-le attentivement avant de chercher plus loin.

Erreurs CEL courantes

Ces erreurs apparaissent lors du type-checking de la policy ou à l'exécution. Elles sont souvent dues à des champs optionnels non testés.

Erreur	Cause	Solution
`undefined field 'xxx'`	Champ inexistant	Utiliser `has(object.field)`
`params missing`	ConfigMap absent	Créer le ConfigMap
`type mismatch`	Mauvais type (string vs int)	Vérifier le schema

Exemple de type-checking dans le status :

status:
  typeChecking:
    expressionWarnings:
    - fieldRef: spec.validations[0].expression
      warning: |-
        ERROR: undefined field 'replicas'

Ce qu'il faut savoir faire vite à l'examen

L'épreuve CKS est chronométrée et ne récompense pas l'écriture de policies sophistiquées. Sur les six réflexes ci-dessous, les points 3 et 4 sont ceux qui font perdre le plus de temps quand ils manquent : chercher un binding à la main ou confondre un refus PSA avec un refus VAP coûte plusieurs minutes sur une question qui en vaut peu. Entraînez-les en priorité.

Reconnaître quand une admission policy est le bon levier (vs PSA, RBAC)
Lire rapidement une ValidatingAdmissionPolicy existante
Trouver le binding qui applique une policy
Identifier la source d'un refus (VAP, PSA, quota, webhook...)
Corriger une expression CEL simple (has(), exists(), all())
Créer une policy basique en moins de 5 minutes

Template minimal à mémoriser

Ce squelette contient le strict nécessaire pour qu'une policy s'applique réellement, et rien d'autre. Deux points à ne pas oublier sous pression : le policyName du binding doit correspondre exactement au nom de la policy, une faute de frappe ne produit aucune erreur au kubectl apply et la règle reste sans effet ; et sans validationActions: [Deny], le binding se contente d'auditer. Le namespaceSelector suppose que le namespace cible porte bien le label, à vérifier avec kubectl get ns --show-labels.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: my-policy
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
  validations:
    - expression: "!object.spec.hostNetwork"
      message: "hostNetwork interdit"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: my-policy-binding
spec:
  policyName: my-policy
  validationActions: [Deny]
  matchResources:
    namespaceSelector:
      matchLabels:
        enforce-policy: "true"

Match conditions avancées

Les matchConditions s'évaluent avant les validations et servent à écarter des requêtes que la policy ne doit jamais examiner. La distinction avec matchConstraints compte : ce dernier filtre par type de ressource, les matchConditions filtrent par contenu de la requête en CEL, avec accès à request et donc à l'utilisateur appelant. C'est le mécanisme qui évite le scénario classique du cluster bloqué : une policy trop large qui refuse les Pods système empêche le cluster de se réparer, et vous ne pouvez plus déployer le correctif. Excluez systématiquement les namespaces kube-* et les comptes system: avant de passer en Deny.

spec:
  matchConditions:
    - name: exclude-system-namespaces
      expression: '!request.namespace.startsWith("kube-")'
    - name: exclude-system-users
      expression: '!request.userInfo.username.startsWith("system:")'

À retenir

VAP est GA depuis 1.30, MAP est GA depuis 1.36, Kubernetes a désormais un duo natif validation + mutation, sans webhook
VAP ne remplace pas PSA, RBAC ou NetworkPolicy, choisir le bon outil
3 ressources : Policy + Binding + Paramètre (optionnel)
Variables CEL : object, oldObject, request, params
Diagnostic : kubectl get validatingadmissionpolicies,validatingadmissionpolicybindings puis describe (ces ressources n'ont aucun nom court, kubectl get vap renvoie une erreur)
Supply Chain : VAP peut restreindre les registries, mais ne vérifie pas les signatures
Pour la CKS : savoir créer une policy simple ET identifier la source d'un refus

Testez vos connaissances

Le quiz porte sur les arbitrages du guide, pas sur la mémorisation de la syntaxe CEL : distinguer VAP de PSA et de RBAC, savoir quelle ressource manque quand une policy reste sans effet, identifier la source d'un refus.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

8 min.

70% 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

Prochaines étapes

Pod Security Standards Profils de sécurité prêts à l'emploi

Kyverno Policies avec mutation et génération

Gatekeeper OPA/Rego pour Kubernetes

VAP vs Kyverno vs Gatekeeper Comparatif détaillé pour choisir