Un webhook d’admission insère un appel réseau synchrone dans le chemin critique de toute création ou modification d’objet Kubernetes : le serveur API attend sa réponse avant d’accepter quoi que ce soit. Ce point de contrôle est puissant, et c’est exactement ce qui en fait un point de défaillance unique si sa fiabilité n’a pas été pensée au même niveau que celle du serveur API lui-même.

Deux types, un ordre d’exécution précis

Un webhook de mutation s’exécute en premier et peut réécrire l’objet avant qu’il soit persisté : injecter un sidecar, poser une valeur par défaut, forcer une étiquette. Un webhook de validation s’exécute ensuite, sur l’objet déjà muté, et ne peut qu’accepter ou refuser, jamais modifier. Cet ordre n’est pas arbitraire : il garantit que la validation s’applique à l’objet final, tel qu’il sera réellement persisté, pas à sa version d’origine avant mutation.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: require-signed-images
webhooks:
  - name: verify.signatures.example.com
    clientConfig:
      service:
        name: policy-controller
        namespace: policy-system
    rules:
      - apiGroups: [""]
        resources: ["pods"]
        operations: ["CREATE"]
    failurePolicy: Fail
    timeoutSeconds: 5

failurePolicy : le compromis qui décide tout

failurePolicy: Fail refuse la requête si le webhook est injoignable ou dépasse son timeoutSeconds : sécurité maximale, mais un webhook en panne bloque alors tous les déploiements qui déclenchent sa règle, potentiellement y compris sa propre mise à jour si elle passe par le même chemin. failurePolicy: Ignore fait l’inverse : la requête est admise malgré l’échec du webhook, ce qui préserve la disponibilité du cluster au prix d’un contrôle silencieusement contourné exactement au moment où il aurait le plus servi.

# Vérifier la latence réelle du webhook avant de choisir
# Fail : un p99 proche du timeoutSeconds annonce des problèmes
kubectl get --raw /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations

Il n’existe pas de bon réglage universel : un webhook qui bloque des créations de Secret en production justifie Fail (le risque d’un Secret non conforme dépasse celui d’un blocage temporaire) ; un webhook cosmétique sur des ressources non critiques justifie Ignore. La décision se prend ressource par ressource, jamais par défaut.

Le timeout, sous-estimé jusqu’à l’incident

timeoutSeconds (5 secondes par défaut, 30 au maximum) doit rester nettement inférieur au temps de réponse réel du service de webhook, pas égal à sa moyenne observée : une moyenne à 2 secondes avec une queue de distribution qui monte à 6 secondes sous charge dépasse un timeout de 5 secondes exactement au moment où le cluster est le plus sollicité, généralement le pire moment pour perdre des déploiements. Un webhook lent sous charge normale devient un webhook qui échoue sous forte charge, un couplage qui n’apparaît qu’en marge d’un incident plus large.

ValidatingAdmissionPolicy : l’alternative sans réseau

Depuis Kubernetes 1.30, ValidatingAdmissionPolicy permet d’exprimer des règles de validation directement dans l’API server via CEL (Common Expression Language), sans appel réseau vers un service externe. Le gain est structurel : plus de latence réseau, plus de point de défaillance externe, plus de failurePolicy à arbitrer pour les règles qui s’y prêtent.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-run-as-non-root
spec:
  validations:
    - expression: "object.spec.securityContext.runAsNonRoot == true"
      message: "Les pods doivent définir runAsNonRoot: true"

La contrepartie : CEL reste plus limité qu’un webhook complet écrit dans un langage généraliste, insuffisant pour une logique de validation qui a besoin d’appeler un service externe (vérifier une signature auprès d’un registre, par exemple). Les deux mécanismes coexistent : ValidatingAdmissionPolicy pour les règles auto-suffisantes, un webhook classique pour celles qui ont réellement besoin d’un appel externe.

À retenir

Un webhook d’admission insère un appel réseau synchrone dans le chemin critique de l’API server, un point de contrôle puissant qui devient un point de défaillance unique dès que sa fiabilité n’égale pas celle du serveur API. failurePolicy se décide ressource par ressource, jamais par défaut ; timeoutSeconds doit couvrir la queue de distribution réelle du service, pas sa moyenne. ValidatingAdmissionPolicy élimine ce risque pour les règles auto-suffisantes exprimables en CEL, un mécanisme à connaître avant d’ajouter un webhook de plus au chemin critique d’un cluster en industrialisation CI/CD.