Política en el clúster, sin el webhook que lo tira

El incidente es siempre el mismo. Se escribe una política que exige límites de recursos en todos los pods. Se aplica en modo de bloqueo en todo el clúster un jueves. Todo lo que ya está corriendo sigue corriendo, así que parece que va bien. Después se reemplaza un nodo por la noche, el DaemonSet de sistema que no tenía límites no puede admitirse, y el clúster pierde su agente de registro y sus pods de red en ese nodo. Nadie conecta la caída con una política aplicada catorce horas antes.

El control de admisión es potente precisamente porque está en el camino de toda escritura al servidor de API. Por eso mismo el despliegue importa más que la herramienta.

Para qué sirve el control de admisión

Tres trabajos, y merece la pena separarlos porque necesitan reglas distintas.

Validación rechaza objetos que incumplen una regla: nada de contenedores privilegiados, nada de etiquetas latest, nada de balanceadores públicos en este namespace, etiquetas obligatorias para atribuir coste.

Mutación rellena cosas: peticiones de recursos por defecto, la inyección de un sidecar, un conjunto estándar de etiquetas, un secreto de descarga de imágenes. La mutación está infravalorada y suele ser la opción más amable, porque arregla el manifiesto en vez de rechazarlo.

Escaneo en segundo plano informa sobre objetos que ya existen. La aplicación solo afecta a escrituras nuevas, así que sin escaneo en segundo plano no tienes ni idea de qué parte del clúster incumpliría la política hoy.

Antes de escribir nada a medida, activa la admisión de seguridad de pods en su nivel base o restringido. Viene dentro de Kubernetes, no necesita controlador y cubre la mayor parte de aquello para lo que los equipos escriben sus diez primeras políticas. Los motores de política son para lo que eso no cubre.

Elegir entre los dos

Kyverno expresa las políticas como recursos de Kubernetes en YAML. No hay un lenguaje aparte: escribes condiciones de coincidencia y una regla de validación, mutación o generación. La generación es un rasgo diferencial, creando una política de red por defecto o una copia de un secreto en cada namespace nuevo, lo que resulta genuinamente útil para el problema de aprovisionar namespaces. El precio del enfoque en YAML es que la lógica compleja se vuelve verbosa.

OPA Gatekeeper usa Rego, un lenguaje de políticas de verdad, con plantillas de restricción que definen la lógica y restricciones que la instancian con parámetros. Rego es más capaz para reglas complejas y se usa mucho más allá de Kubernetes, así que una organización que ya use OPA para autorización de API consigue un solo lenguaje en todas partes. El precio es que Rego tiene una curva de aprendizaje real y depurarlo no resulta agradable para alguien que escribe YAML todo el día.

La recomendación honesta: si tu equipo es nativo de Kubernetes y tus políticas tienen forma de "exige este campo, prohíbe ese valor", Kyverno te lleva antes y más gente del equipo puede mantenerlo. Si ya ejecutas OPA en otro sitio, o tus políticas necesitan lógica real sobre varios recursos, Gatekeeper. Los dos son proyectos de la fundación con comunidades activas y los dos funcionan. La disciplina de despliegue de abajo importa más que la elección.

El despliegue que no provoca una caída

Cuatro etapas, y saltarse cualquiera es como ocurre la historia del principio.

1. Auditar. Despliega la política en modo auditoría o simulación y enciende el escaneo en segundo plano. No hagas nada más durante una semana. Ahora tienes un informe de todos los objetos existentes que incumplen la regla, que es el número que de verdad necesitabas antes de decidir si la política es razonable.

2. Arreglar el atraso. Recorre los incumplimientos con los equipos dueños. Es la parte lenta y es donde está el valor. Una política aplicada sobre un entorno limpio es una barandilla; aplicada sobre uno sucio es un generador de caídas.

3. Avisar. Pasa a un modo que admita el objeto pero devuelva un aviso a quien lo aplica. La gente ve el mensaje en la salida de su pipeline y arregla las cosas antes de que llegue el bloqueo.

4. Aplicar, namespace a namespace. No en todo el clúster el primer día. Empieza por un equipo que haya dado su acuerdo y después amplía. Mantén la política en modo auditoría para los namespaces que aún no bloquean, para poder ver el avance.

Anuncia cada etapa. Una política que empieza a rechazar despliegues en silencio genera tickets de soporte que culpan al equipo de plataforma de un fallo misterioso.

Las exclusiones no son opcionales

Excluye los namespaces de sistema desde el principio, y hazlo de forma explícita en vez de confiar en un valor por defecto. El namespace del sistema contiene cargas que no controlas y cuyos manifiestos fija el proveedor, y una política que las bloquee puede impedir que un nodo se una al clúster.

Más allá de eso, excluye los namespaces de los componentes que tienen que sobrevivir para poder arreglar problemas: tu complemento de red, tus controladores de almacenamiento, tu monitorización y el propio motor de política. Un motor de política que bloquea su propia actualización es una tarde genuinamente incómoda.

Escribe las exclusiones como una lista explícita dentro de la política y no como un ajuste global, para que quien lea vea qué está exento y por qué. Revisa la lista cada trimestre, porque las exclusiones añadidas durante un incidente tienden a volverse permanentes.

La política de fallo es el riesgo de verdad

Todo webhook de admisión tiene una política de fallo que decide qué pasa cuando el webhook no está accesible. Es el ajuste más trascendente de todo el sistema.

Fallar cerrado significa que el servidor de API rechaza la escritura. Es lo correcto desde la seguridad: una política que se esquiva dejándola sin servicio no es un control. También significa que si tu motor de política está caído, no se puede desplegar nada, incluido el arreglo, y en el peor caso no se pueden crear pods nuevos.

Fallar abierto significa que las escrituras pasan sin comprobar. Más seguro operativamente, y significa que un atacante capaz de interrumpir el webhook puede saltarse tus políticas.

La posición viable es fallar cerrado en las políticas que de verdad importan para seguridad, fallar abierto en las de higiene, más las medidas operativas que hacen improbable el fallo: varias réplicas repartidas entre nodos y zonas, un presupuesto de interrupción, tiempos de espera generosos y una alerta sobre la latencia y la tasa de error del webhook. Vigila también la caducidad del certificado, porque un certificado de webhook caducado produce exactamente la misma caída que un controlador muerto.

Ten claro tu procedimiento de emergencia. Borrar la configuración del webhook restaura el servicio de inmediato y desactiva tus políticas, y alguien debería haberlo practicado.

Políticas como código, revisadas como código

Las políticas van en git, desplegadas por el mismo pipeline que todo lo demás, con la misma revisión. Eso es lo que las convierte en evidencia: un auditor que pregunta cómo impides los contenedores privilegiados recibe un fichero versionado, un registro de aprobación y un informe de cumplimiento actual, que es una respuesta mucho mejor que una captura de pantalla.

Pruébalas. Los dos motores tienen una herramienta de línea de comandos que evalúa una política contra un manifiesto, así que un pull request que cambia una política puede ejecutar un juego de manifiestos que deberían pasar y que deberían fallar. Sin eso, la primera prueba de un cambio de política es producción.

Esto alimenta además directamente el mapeo de controles: una sola política puede satisfacer un requisito de varios marcos a la vez, como se argumenta en un conjunto de controles para cuatro marcos. El mismo instinto aplica en la capa de nube, donde la disciplina de despliegue de Azure Policy como código tiene la misma forma.

Lo que se olvida

• Aplicar no toca lo que ya existe. El escaneo en segundo plano es lo que te dice la verdad sobre el entorno.
• El orden de las mutaciones importa. Varios webhooks de mutación se aplican en secuencia y pueden pelearse. Comprueba el resultado, no la intención.
• La latencia está en cada escritura. Una política lenta añade latencia a la creación de todos los objetos del clúster, y eso se ve como despliegues lentos y escalados lentos.
• Las políticas necesitan dueño. Una regla que nadie mantiene se convierte en una lista de exclusiones que crece hasta que la regla no significa nada.
• Empieza con menos políticas de las que quieres. Diez políticas bien entendidas y aplicadas ganan a sesenta en modo auditoría que nadie lee.

Qué hacer esta semana

Despliega tu motor de política con escaneo en segundo plano y una sola política en modo auditoría, que exija peticiones de recursos en todos los pods. No la apliques. Lee el informe. El número de incumplimientos te dice exactamente a qué distancia está el entorno de donde creías que estaba, y ese número es el argumento para el trabajo. Lo hacemos en la fase de plataforma de un proyecto de seguridad.