Admission Controller de Kubernetes.

La admision en Kubernetes se situa en el pipeline de peticiones del API server despues de la autenticacion y la autorizacion, pero antes de que el objeto se escriba en etcd. Se ejecuta en dos fases ordenadas: los controladores mutating pueden reescribir el objeto (fijar valores por defecto, inyectar un sidecar de Istio/Envoy) y despues los controladores validating lo aceptan o lo rechazan. Entre los controladores integrados estan NamespaceLifecycle, ResourceQuota, ServiceAccount, PodSecurity e ImagePolicyWebhook. Los motores de politicas externos se registran como MutatingWebhookConfiguration/ValidatingWebhookConfiguration, reciben una carga JSON AdmissionReview y devuelven un veredicto de permitir/denegar; aqui es donde se enganchan OPA Gatekeeper y Kyverno. Desde 1.30 (GA), ValidatingAdmissionPolicy embebe expresiones CEL directamente en el API server, eliminando el salto de red al webhook.

La admision es el punto principal de aplicacion de politicas de cadena de suministro y de cargas de trabajo: verificacion de firma de imagenes (Sigstore/cosign), Pod Security Standards e higiene de etiquetas. Eso convierte al propio webhook en un objetivo. El incidente IngressNightmare de marzo de 2025 (CVE-2025-1974, CVSS 9.8, junto con CVE-2025-1097/1098/24514) permitio a un atacante no autenticado alcanzar el endpoint de admission de ingress-nginx e inyectar directivas NGINX, logrando RCE en el pod del controlador y un posible robo de secretos a nivel de todo el cluster; un claro recordatorio de que los endpoints de admision nunca deben quedar expuestos a la red.

En operacion, failurePolicy: Fail con un webhook inalcanzable puede dejar el cluster inservible, asi que acota los webhooks con namespaceSelector, fija timeoutSeconds ajustados y excluye kube-system.

flowchart LR
  U[kubectl / cliente] --> API[API server]
  API --> AUTHN[Autenticacion]
  AUTHN --> AUTHZ[Autorizacion RBAC]
  AUTHZ --> MUT[Admision mutating -> inyectar / default]
  MUT --> SCH[Validacion de esquema y objeto]
  SCH --> VAL[Admision validating + VAP CEL]
  VAL --> D{Permitido?}
  D -->|Rechazar| ERR[Peticion denegada al cliente]
  D -->|Permitir| ETCD[(Persist to etcd)]
  VAL -.policy.-> ENG[OPA Gatekeeper / Kyverno]