Webhook d'admission

Un webhook d’admission est un service que le serveur API Kubernetes appelle en synchrone, avant d’accepter un objet (créer un pod, modifier un déploiement), pour lui demander un avis. Il en existe deux types : le webhook de validation, qui accepte ou refuse la requête sans la modifier, et le webhook de mutation, qui peut réécrire l’objet avant qu’il soit persisté : injecter un sidecar, poser une valeur par défaut, forcer une étiquette.

Ce qui l’exploite en pratique

Un contrôle d’admission comme policy-controller (Sigstore) ou la règle verifyImages de Kyverno s’appuie sur un webhook de validation pour exiger une image dûment signée avant d’admettre un pod : la vérification a lieu au moment précis où l’objet tente d’entrer dans le cluster, pas après coup en audit. C’est le point de contrôle le plus tôt possible dans le cycle de vie d’un objet Kubernetes.

Le risque du failurePolicy: Fail

Le serveur API appelle le webhook à chaque requête concernée, et failurePolicy décide quoi faire si l’appel échoue ou expire. Réglé sur Fail, un webhook injoignable bloque tous les déploiements qui le déclenchent (y compris, potentiellement, celui du webhook lui-même après une mise à jour ratée). C’est un point de défaillance unique explicite : le compromis entre sécurité stricte (Fail) et disponibilité du cluster (Ignore) se décide au cas par cas, jamais par défaut.