Koray Oksay, embajador de CNCF, considera que las organizaciones suelen colocar Kyverno bajo la responsabilidad de los equipos de seguridad. Lo utilizan para validar las configuraciones de Kubernetes, bloquear contenedores que se ejecutan con privilegios de root o imponer estándares de seguridad de los contenedores, y luego dejan de lado una parte importante de sus capacidades. Según el planteamiento de Oksay, esta clasificación mental limita Kyverno al papel de una «puerta de entrada» que impide las configuraciones incorrectas, cuando puede utilizarse como un bloque fundamental sobre el que los equipos de plataformas construyan sus servicios y reglas operativas.
Esta opinión se basa en la experiencia del autor, que comenzó con una presentación en la conferencia KCD Munich de 2023 titulada «Protección de las cargas de trabajo de Kubernetes mediante Kyverno». Después de tres años de trabajo en entornos de producción, afirma que su interés se trasladó a la gobernanza, CEL y el autoservicio de las plataformas, y que describir Kyverno como un «motor de políticas» ya no basta para abarcar su alcance.
¿Por qué no basta con clasificarlo como una herramienta de seguridad?
Oksay no niega las funciones de seguridad de Kyverno. La plataforma puede bloquear configuraciones inseguras, imponer Pod Security Standards y validar las firmas de las imágenes de contenedores. Sin embargo, vincularla únicamente con la seguridad consolida un modelo que concibe la política como una barrera cuyo objetivo principal es rechazar, de modo que el éxito se mide por el número de despliegues que se han impedido.
En cambio, el autor identifica cuatro funciones principales de Kyverno: validación, modificación, generación y validación de imágenes. La validación pertenece directamente al modelo de barrera; la modificación cambia los recursos antes de introducirlos en el clúster; la generación crea recursos nuevos en respuesta a determinados eventos; mientras que la validación de imágenes se centra en generar confianza en ellas, no solo en bloquear amenazas. Por ello, considera que tres de las cuatro funciones tienen una naturaleza constructiva, pero muchas organizaciones solo utilizan políticas de validación.
¿Qué significa ser un componente fundamental de la plataforma?
Oksay utiliza la expresión «componente fundamental» en un sentido cercano al que tiene en los lenguajes de programación: un bloque pequeño y comprensible que puede combinarse para construir sistemas más grandes. Para que este bloque desempeñe un papel efectivo en la plataforma, debe ocultar la complejidad a los desarrolladores, ofrecer garantías automáticas, integrarse con otros bloques y estar disponible mediante autoservicio, en lugar de depender de solicitudes manuales o colas de soporte.
En este sentido, las políticas de Kyverno se parecen a componentes como Pods, Services, ConfigMaps y las composiciones de Crossplane. Transforman las reglas adoptadas por la organización en un comportamiento automático dentro de la plataforma.
¿Cómo pueden utilizarlo los equipos de plataformas?
- Preparación de los espacios de nombres: al crear un espacio de nombres, Kyverno puede generar NetworkPolicy, ResourceQuota, LimitRange y RoleBindings predeterminados, de modo que el espacio aparezca preparado sin pedir al desarrollador que recuerde una lista de pasos manuales.
- Inyección de contenedores sidecar: se pueden añadir agentes de monitorización, agentes de red o contenedores de sincronización de secretos a las especificaciones de los Pods durante la fase de admisión, manteniendo sencillo el archivo Deployment.
- Reescritura de referencias de imágenes: una referencia como nginx:1.25 puede transformarse en mirror.internal/nginx:1.25 para que las operaciones de extracción pasen por un espejo interno, en lugar de pedir a cada desarrollador que añada manualmente el prefijo.
- Adición de solicitudes de recursos predeterminadas: en lugar de bloquear los Pods que no especifican solicitudes de CPU y memoria, se pueden inyectar valores adecuados y modificarlos cuando sea necesario.
- Asignación de etiquetas de propiedad: se pueden añadir etiquetas del equipo, del centro de costes y del entorno cuando los valores sean claros, o imponerlas cuando la ambigüedad tenga un impacto significativo.
¿Qué cambia en la práctica?
Estos usos reúnen una misma idea: convertir una convicción organizativa en una garantía automática e invisible. La regla puede ser de seguridad, como impedir contenedores con privilegios elevados; operativa, como imponer límites de recursos; o financiera, como vincular cada recurso a una etiqueta de centro de costes. En lugar de que estas reglas permanezcan en la wiki, en listas de comprobación o en el conocimiento de un solo ingeniero, se convierten en una política escrita como código, almacenada en Git y aplicada mediante herramientas de GitOps y Kyverno.
Esta perspectiva propone tratar la política como la interfaz de la plataforma para expresar la intención de la organización. Al aplicarla, las funciones de Kyverno se convierten en distintos niveles: la validación proporciona barreras de protección, la modificación traza «caminos pavimentados» para los desarrolladores, la generación ofrece plantillas o preparaciones iniciales y la validación de imágenes construye confianza.
Los equipos también tratarán las políticas como productos con versiones, usuarios, ciclos de retirada y excepciones rastreables. El despliegue de una política puede comenzar con la auditoría, continuar con las advertencias y terminar con una imposición gradual. El autor también señala posibles desafíos de coordinación cuando una política modifica un recurso que Argo CD o Flux considera de su propiedad, lo que podría provocar bucles de sincronización.
La conclusión que presenta Oksay es que leer Kyverno únicamente como una herramienta de seguridad oculta una parte importante de su interfaz y sus capacidades. En su opinión, no es un guardián situado en la entrada del clúster, sino una capa que conecta las opiniones del equipo de plataformas con el comportamiento real de los recursos y las aplicaciones.