Políticas de admisión

Si el único control está en la cadena, basta con no usar la cadena: una persona con permisos puede desplegar una imagen desde su portátil, una vieja o una copiada de otro sitio. El controlador de admisión está en el camino del clúster, no en el de la cadena: cada pod que se quiere crear pasa por él, venga de donde venga. Allí se comprueba lo que la cadena ya prometía —registro permitido, etiqueta fija, firma válida, usuario sin privilegios— y se rechaza o se anota lo que no cumpla.

La admisión no sustituye a los controles de la cadena: los respalda. La cadena evita que lo malo se construya; la admisión evita que lo malo se ejecute.

Una regla de admisión tiene un modo. En Enforce, un pod que la incumple se deniega: no se crea. En Audit, el pod se admite y la violación se registra. El modo de auditoría existe para poder medir sin romper: se enciende una regla, se ve cuántos pods la incumplen, se corrigen, y solo cuando el número es cero —o lo que queda está en excepciones con dueño— se pasa a Enforce. Una regla que pasa de golpe a bloquear, sin medirla antes, tumba servicios en producción y hace que el equipo apague la política.

El informe de admisión de las últimas 24 horas resume las violaciones por regla. Lee el resumen y mira cuál, de las que solo avisan, es la que más se está incumpliendo.

Toda política de admisión trae una lista de espacios de nombres excluidos, y es donde suelen aparecer los agujeros. Algunas exclusiones son legítimas: los componentes del propio clúster no pueden cumplir reglas pensadas para aplicaciones. Pero cada exclusión es un lugar donde ninguna regla se aplica, y una exclusión sin dueño, sin fecha y sin motivo es un espacio por el que cualquier imagen entra sin que nadie responda. Se revisan como se revisa una excepción de escaneo: con responsable, motivo y vencimiento.

Lee el archivo de excepciones de la política y busca la exclusión que no cumple esas tres condiciones.

Pasar una regla de Audit a Enforce es una migración, no un interruptor. El orden que funciona: primero medir (cuántos pods la incumplen y cuáles), después corregir lo que se pueda, luego registrar las excepciones legítimas con dueño y fecha, avisar a los equipos con una fecha de corte y, solo entonces, activar el bloqueo. Y una vez activado, se vigila el primer día y se deja un camino de vuelta atrás. Hacerlo al revés —bloquear primero y corregir cuando se quejen— enseña al resto de la empresa que la seguridad es la que tumba los servicios.

La pregunta que decide el calendario de la migración es: «si hoy todas las reglas estuvieran en Enforce, ¿cuántos servicios dejarían de arrancar?». Se contesta con el informe de admisión, contando pods, no violaciones: un pod que incumple dos reglas es un solo pod rechazado. Y se descuentan los que el clúster ya está denegando hoy, porque ya no entran. Ese número, y la lista de quiénes son, es lo que se lleva a los equipos cuando se les pide corregir antes de la fecha de corte.