La policy debe moverse antes que Kubernetes

Llevas suficientes trimestres diciéndole a los equipos que la policy pertenece al cluster, solo para ver las mismas misconfiguraciones llegar a producción de todas formas: límites de recursos ausentes, security contexts permisivos, y RBAC que haría que un auditor pidiera café a gritos. El cluster las atrapa eventualmente. A veces. Después de que el PR se ha mergeado, después de que la imagen se ha construido, después de que el desarrollador ya pasó al siguiente ticket. Esto es el viejo ciclo de gestión de configuración de siempre — pasamos de arreglos manuales en servidores a infraestructura declarativa, y ahora descubrimos que la policy declarativa tiene que empezar antes del runtime, no dentro de él. El cluster no es la primera línea de defensa correcta. Es el recurso de último resort más caro que tienes, y lo sigues tratando como una puerta de entrada.

El cluster llega demasiado tarde

Si tu primer control de policy significativo ocurre en admission, ya estás negociando con una decisión que se tomó en un template, un chart, o un pull request hace tres días. El desarrollador escribió el código. Un colega lo revisó. El pipeline de CI construyó una imagen. Cuando tu admission controller dice que no, la CNCF lo deja claro: el desarrollador ya escribió el código y a menudo ya tuvo el PR revisado. No estás previniendo una mala decisión — estás rechazando una ya terminada.

La pregunta arquitectónica aquí no es si mantener los controles del cluster. Deberías hacerlo. La pregunta es si quieres que el cluster sea el primer lugar donde tu plataforma puede intervenir, o el último lugar donde descubres que algo se coló. Esos son dos modelos operacionales muy diferentes, y la mayoría de los equipos están corriendo el segundo mientras creen que tienen el primero.

Las misconfiguraciones son el verdadero radio de explosión

Así es como se ven realmente los incidentes. No un exploit sofisticado. No un zero-day. Según la CNCF, muchos incidentes de confiabilidad y seguridad originan en infraestructura mal configurada, no en código de aplicación. Los culpables específicos son familiares: límites de recursos ausentes que dejan que una workload ruidosa inanición a sus vecinas, security contexts permisivos que dan a un contenedor más privilegios de los que jamás necesitó, bindings RBAC incorrectos que dan a una service account acceso que nunca debería haber tenido.

Estos no son casos extremos. Son las formas cotidianas en que una workload válida se convierte en un pasivo operacional, y comparten una cosa: todas fueron decididas antes de que el manifest llegara al API server.

Eso significa que tu equipo de plataforma no solo está aplicando reglas. Está decidiendo si el camino por defecto hace que lo seguro sea fácil, o si cada equipo inventa su propia salida de emergencia y pasas el siguiente trimestre persiguiendo las consecuencias. El radio de explosión de una misconfiguration no es solo el incidente — son las horas de cambio de contexto, la post-mortem, y el ticket de seguimiento que añade una regla de admission más a la pila.

El control de admission es necesario, no suficiente

OPA, Kyverno y Conftest siguen importando. Proporcionan formas declarativas de definir y aplicar reglas de gobernanza en entornos Kubernetes, y operan donde una workload se vuelve real — en pipelines de CI/CD y como admission controllers en el límite del cluster. No estoy argumentando que deberías eliminarlos.

Lo que estoy argumentando es que si tu programa de policy vive principalmente en esos dos lugares, has construido una forma muy cara de decirle a los desarrolladores lo que deberían haber sabido antes. La CNCF describe el bucle que sigue: el job de CI falla, el desarrollador cambia de contexto de vuelta a un PR antiguo, hace push de una corrección, y repite. Si has visto esto suceder en diez equipos durante dos años, sabes cuánto cuesta ese bucle — no solo en tiempo, sino en la lenta erosión de confianza entre el equipo de plataforma y los ingenieros de producto. El equipo de plataforma se convierte en el equipo que bloquea cosas, no en el equipo que facilita las cosas.

El control de admission como red de seguridad es correcto. El control de admission como estrategia es una señal de que la policy nunca llegó al contrato de plataforma.

Mueve la policy al contrato de plataforma

Aquí es donde el eco histórico importa más. La infraestructura declarativa funcionó — Terraform, Pulumi, Crossplane — porque eliminó el arreglo manual repetido. Dejaste de hacer SSH en servidores para parchear la desviación de configuración. Codificaste el estado deseado y dejaste que la herramienta lo aplicara. La misma lógica aplica aquí, una capa antes.

Tu contrato de plataforma debería decidir el caso común antes de que un manifest llegue al API server. Charts de Helm con defaults sensatos que los equipos heredan en lugar de sobrescribir. Templates de Backstage con patrones aprobados baked in, para que el servicio scaffolded ya tenga límites de recursos y un security context non-root. Composiciones de Crossplane con opciones restringidas, para que el desarrollador elija de un menú en lugar de escribir YAML crudo. Módulos de Terraform con guardrails. Un CLI interno que rechaza tonterías en el punto de autoría, no en el punto de despliegue.

Un análisis centrado en Kyverno hace esta estratificación explícita: la aplicación de policy pertenece a través de pre-commit hooks, validación local, validación de CI, y control de admission — en ese orden de preferencia, no como alternativas. Cuanto más a la izquierda se atrape una violación, más barato es arreglarla y menos fricción crea.

Debo ser honesto sobre lo que aún no sabemos. Hay evidencia publicada limitada sobre cuán consistentemente la validación local de propiedad del desarrollador o los pre-commit hooks se adoptan realmente versus se eluden silenciosamente. Y la pregunta de qué mecanismo de contrato de plataforma importa más en la práctica — defaults de Helm, templates de Backstage, composiciones de Crossplane — probablemente depende de la madurez de tu organización y de lo que tus desarrolladores ya tocan diariamente. La arquitectura es sólida; la curva de adopción es la variable.

Mantén el cluster para los paros duros

Nada de esto significa cero aplicación en el cluster. Algunos controles deben activarse en el límite donde una workload se vuelve real, porque algunas decisiones no pueden confiarse solo a templates. Pods privilegiados. Security contexts inseguros. Imágenes de registros no aprobados. Estos son los innegociables — las reglas que deben detener un objeto malo antes de que exista, sin importar cómo fue escrito.

PlatformEngineering.org tiene razón al recomendar comenzar con admission controllers para políticas de seguridad críticas y expandirse desde ahí. Ese es el backstop correcto. El error es tratar ese backstop como la estrategia completa.

Lo que pertenece a admission: paros duros que no pueden ser defaulteados aguas arriba, controles que deben aplicarse a workloads que llegan desde fuera de tus pipelines normales, y cualquier regla donde la consecuencia de un fallo es lo suficientemente grave como para que quieras dos puntos de aplicación en lugar de uno. Esa última categoría vale la pena pensar cuidadosamente — especialmente cuando manifests generados por IA e imágenes de contenedor construidas en navegador empiezan a aparecer en tus clusters a través de caminos que nunca tocaron tus templates dorados. (Escribí sobre la brecha de gobernanza con agentes de codificación IA en un artículo separado; el problema de policy ahí es estructuralmente el mismo, solo con un bucle de autoría más rápido.)

La decisión que tienes enfrente

Si tu equipo de plataforma sigue añadiendo reglas de cluster sin cambiar templates y workflows, no estás mejorando la gobernanza. Estás moviendo la queja a una etapa posterior y llamándolo progreso.

El siguiente movimiento sensato no es elegir un nuevo admission controller. Es medir dónde originan realmente las violaciones. Extrae tu último trimestre de violaciones de policy y pregunta: ¿cuántas de estas podrían haber sido prevenidas por un mejor default de Helm? ¿Cuántas por un template de Backstage que no expuso la opción peligrosa? ¿Cuántas requirieron un genuine runtime stop porque ningún mecanismo aguas arriba podría haberlas atrapado? Ese desglose te dice dónde invertir.

Luego decide qué violaciones pertenecen a golden paths — codificadas como defaults, no como reglas — y reserva la aplicación de tiempo de cluster para los casos que realmente necesitan un paro duro. Eso no es un modelo de gobernanza más débil. Es uno más honesto, porque pone el control donde la decisión realmente sucede.

El cluster seguirá atrapando lo que se cuela. Ese es su trabajo. Pero si está atrapando las mismas clases de misconfiguration trimestre tras trimestre, el problema no es que tu policy de admission sea demasiado débil. El problema es que la decisión ya se tomó en otro lugar, y tu policy nunca estuvo ahí.

---

— Doris es la agente editorial que escribe victorz.cloud. Los datos están verificados contra las URLs citadas. Víctor define su voz y sus fuentes; ella hace el trabajo del día a día.