Admission Controller Kubernetes.

L'admission Kubernetes se situe dans le pipeline de requetes de l'API server apres l'authentification et l'autorisation, mais avant que l'objet ne soit ecrit dans etcd. Elle s'execute en deux phases ordonnees : les controleurs mutating peuvent reecrire l'objet (definir des valeurs par defaut, injecter un sidecar Istio/Envoy), puis les controleurs validating l'acceptent ou le rejettent. Les controleurs integres incluent NamespaceLifecycle, ResourceQuota, ServiceAccount, PodSecurity et ImagePolicyWebhook. Les moteurs de politiques externes s'enregistrent comme MutatingWebhookConfiguration/ValidatingWebhookConfiguration, recoivent une charge JSON AdmissionReview et rendent un verdict autoriser/refuser : c'est la que se branchent OPA Gatekeeper et Kyverno. Depuis la 1.30 (GA), ValidatingAdmissionPolicy embarque des expressions CEL directement dans l'API server, supprimant le saut reseau vers le webhook.

L'admission est le principal point d'application des politiques de chaine d'approvisionnement et de charge de travail : verification de signature d'images (Sigstore/cosign), Pod Security Standards et hygiene des labels. Cela fait du webhook lui-meme une cible. L'incident IngressNightmare de mars 2025 (CVE-2025-1974, CVSS 9.8, avec CVE-2025-1097/1098/24514) a permis a un attaquant non authentifie d'atteindre l'endpoint admission d'ingress-nginx et d'injecter des directives NGINX, obtenant une RCE dans le pod du controleur et un vol potentiel de secrets a l'echelle du cluster : un rappel brutal que les endpoints d'admission ne doivent jamais etre exposes sur le reseau.

En exploitation, failurePolicy: Fail avec un webhook injoignable peut rendre le cluster inutilisable, il faut donc cadrer les webhooks avec namespaceSelector, definir des timeoutSeconds serres et exclure kube-system.

flowchart LR
  U[kubectl / client] --> API[API server]
  API --> AUTHN[Authentification]
  AUTHN --> AUTHZ[Autorisation RBAC]
  AUTHZ --> MUT[Admission mutating -> injecter / defaut]
  MUT --> SCH[Validation schema et objet]
  SCH --> VAL[Admission validating + VAP CEL]
  VAL --> D{Autorise ?}
  D -->|Rejeter| ERR[Requete refusee au client]
  D -->|Autoriser| ETCD[(Persist to etcd)]
  VAL -.policy.-> ENG[OPA Gatekeeper / Kyverno]