Controles de admisión como lección

Un controlador de admisión interviene cuando se envía un objeto al servidor de API: puede rechazarlo, modificarlo o dejarlo pasar. No actúa sobre los pods que ya están en marcha: activar una política estricta hoy no cambia lo desplegado ayer hasta que ese objeto se vuelva a crear o a modificar. Tampoco limita quién puede entrar al clúster: una credencial válida sigue siendo válida.

La admisión limita qué puede llegar a ser un pod; no sustituye la gestión de credenciales ni la lectura de los registros.

Pod Security Admission trabaja por namespace con tres modos: enforce rechaza el pod que no cumple el perfil, audit lo deja pasar pero anota la infracción en el registro de auditoría, y warn lo deja pasar y avisa a quien lo despliega. Los perfiles son tres: privileged, baseline y restricted.

El inventario dice qué namespace tiene el perfil más exigente en los tres modos a la vez: es el único donde un pod que no cumple se rechaza y quien lo despliega se entera.

En modo audit, cada infracción queda anotada con el campo concreto del pod que no cumple. Leer esas anotaciones sirve para dos cosas: saber qué habría rechazado un enforce y qué cambios hay que hacer en los manifiestos antes de activarlo.

Una sola infracción repetida en cada contenedor no se cuenta como varios hallazgos: se cuentan los objetos distintos que dejaron avisos, porque cada uno hay que corregirlo. Un mismo objeto con varias filas es un solo trabajo con varias correcciones.

El informe no promete lo que la admisión no puede dar. Y activa los controles por etapas: se lee lo que el modo de aviso encontró, se corrigen los manifiestos y solo entonces se pasa a rechazar. Activar el modo estricto sobre lo desplegado sin revisar rompe aplicaciones y la próxima vez nadie querrá activar nada.