Admission controller
Un admission controller es un componente que intercepta las peticiones al servidor de API de Kubernetes después de la autenticación y la autorización, pero antes de que el objeto se guarde, y puede rechazarlas o modificarlas. Es el punto donde una política de clúster se aplica de verdad en vez de quedarse documentada.
Hay dos clases y la diferencia importa al leer una configuración. Un controlador de mutación cambia el objeto a su paso, por ejemplo inyectando un sidecar o fijando un contexto de seguridad por defecto. Un controlador de validación solo acepta o rechaza. La mutación se ejecuta primero, así que una política que valida un campo que otro controlador reescribe después está comprobando la versión equivocada del objeto.
Esto es lo que impide que un pod pida privilegios de nivel de host, un host path montado o un espacio de nombres de red del host, que son las configuraciones que convierten el compromiso de una aplicación en un escape de contenedor. Sin aplicación en la admisión, el planificador concede esas peticiones porque en el clúster no hay nada mirando.
Los modos de fallo que buscamos son siempre los mismos. Un webhook configurado para fallar abriendo, de manera que un motor de políticas que no está disponible o va saturado permite todo en silencio. Espacios de nombres excluidos de la política por motivos de operación y usados después para cargas de trabajo corrientes. Políticas que cubren los pods y no los controladores que crean pods, con lo que la misma especificación llega intacta a través de un deployment. Y una cuenta de servicio con permiso para modificar la propia configuración de la política, que reduce el control entero a un solo permiso. Comprobar que la política de seguridad de Kubernetes de un clúster aguanta frente a una carga de trabajo deliberadamente no conforme forma parte de las pruebas de cloud donde intentamos colar una carga de trabajo saltándose la política.