Asegura Kubernetes con Política como Código

Kyverno es un policy engine nativo de Kubernetes que funciona como admission controller para aplicar reglas de seguridad y compliance automáticamente. Junto con Argo CD, permite gobernar qué recursos sí o no pueden desplegarse en tu cluster —sin scripts, sin webhooks manuales, todo declarado en YAML estándar. Es, básicamente, un guardián que intercepta cada manifesto antes de que toque el cluster.

¿Qué es policy-as-code en Kubernetes y por qué Kyverno?

Imaginate que manejás un cluster Kubernetes con 50 equipos diferentes deployando aplicaciones. Sin guardrails, alguien inevitablemente va a desplegar un pod corriendo como root, exponiendo puertos internos, usando imágenes sin scanear, o montando la filesystem del host. Los scripts de validación manual no escalan. Eso es exactamente para qué existe policy-as-code.

Policy-as-code en Kubernetes significa escribir reglas declarativas (en YAML, no en bash) que el cluster evalúa automáticamente en cada operación. Esas reglas viven en Git, se versiona con todo lo demás, y Kubernetes las ejecuta sin que nadie tenga que hacer nada manual. Es declarativo en su forma más pura.

Kyverno, según el anuncio de la CNCF publicado el 2 de abril de 2026, es un admission controller que vive en tu cluster y valida cada request antes de que un recurso se cree. Actúa como checkpoint: la aplicación quiere desplegar un pod, llega el manifesto, Kyverno lo evaluá contra tus políticas, y sí o sí lo aprueba, lo rechaza, lo modifica, o genera recursos complementarios. Todo ocurre antes de que el pod exista.

¿Por qué Kyverno y no scripts manuales? Porque los scripts fallan, no se testean, y eventualmente alguien se olvida de correrlos. Kyverno está en el kernel de Kubernetes. No hay forma de bypassearlo (a menos que seas admin y hagas cosas raras).

Los cuatro tipos de políticas: validate, mutate, generate y cleanup

Kyverno soporta cuatro modos de política. Cada uno resuelve un problema diferente.

Validate: bloquear o auditar

Es el más simple: “validá que el manifesto cumpla esto”. Puede tener dos comportamientos.

Block: si el recurso no cumple, se rechaza. Punto. El pod nunca se crea. Ejemplo: “todo pod debe tener un resourceLimit de memoria definido”. Tema relacionado: requisitos de auditoría y compliance.

Audit: si el recurso no cumple, se crea igual pero se logea la violación. Útil cuando estás migrando gente a las nuevas reglas y no querés romper deployments existentes. Después transitás a block cuando todo el mundo sabe cuáles son las reglas.

Mutate: cambiar automáticamente

En lugar de rechazar, Kyverno modifica el manifesto para que cumpla. Ejemplos: agregar automáticamente un securityContext a todo pod, poner labels por defecto, inyectar ConfigMaps. El desarrollador envía un manifesto “incompleto” y Kyverno lo completa.

Generate: crear recursos relacionados

Cuando se crea un recurso, Kyverno puede generar otros. Típico: cuando se crea un Namespace, generar automáticamente un NetworkPolicy restringido, un ResourceQuota, un rolebinding. Una acción genera el esqueleto completo.

Cleanup: limpiar recursos viejos

Borra recursos que ya no cumplen con las políticas, según una condición. Menos común pero útil para higiene.

Kyverno vs OPA Gatekeeper: comparativa y cuándo usar cada uno

Ambos son admission controllers, pero tienen diferencias sustanciales. Acá va una comparativa.

Si tu infraestructura es relativamente estándar (bloquear privilegios, validar recursos, inyectar labels), Kyverno es más rápido de implementar. Si necesitás reglas complejas con mucha lógica condicional, OPA escala mejor. La mayoría de los equipos en 2026 están eligiendo Kyverno cuando empiezan porque el onboarding es casi cero: es YAML que ya conocés.

Integración con Argo CD: GitOps impulsado por políticas

El combo Argo CD + Kyverno es lo que hace que esto sea realmente poderoso.

Argo CD sincroniza manifests desde un repositorio Git. Eso incluye tus políticas de Kyverno —que son solo más manifests YAML. Pushás una política a master, Argo la sincroniza, Kyverno la carga automáticamente. No hay restart, no hay webhook manual, no hay deployment. Es GitOps puro. Cubrimos ese tema en detalle en pipelines de integración continua.

Acá viene lo bueno: si alguien intenta deployar algo que viola una política, Argo CD lo detecta, marca la Application como OutOfSync o Degraded, y lo ve en la UI. El desarrollador mira el error, arregla el manifesto, pushea nuevamente, y todo fluye.

Las políticas pueden correr en dos modos. Enforce: rechaza directamente, probada y confiada. Audit: solo logea, útil mientras migrás. Vos controlás el threshold desde Git, sin tocar el cluster.

Implementación paso a paso: desplegar Kyverno con Argo CD

Si querés arrancar, los pasos son estos.

Paso 1: crear una Application de Argo CD para Kyverno. Apuntá al chart oficial de Kyverno con `syncWave: 1`. Esto asegura que Kyverno se levante primero, antes que cualquier otra Application.

Paso 2: desplegar las políticas baseline. Kyverno publica un repositorio de políticas oficiales en GitHub que son listas para usar. Agregá una Application que apunte a ese repo con `syncWave: 2`. Incluyen validaciones de Pod Security Standards (no root, no privilegios escalados, capacidades peligrosas, etc.).

Paso 3: configurar validationFailureAction. En tus políticas, definís si es `enforce` (rechaza) o `audit` (logea). Empezá con audit durante una semana, validá que no rompés nada, después pasá a enforce.

Paso 4: agregar políticas propias. Escribí tu YAML de Kyverno (es un CRD llamado `ClusterPolicy`) y committealo. Argo lo sincroniza automáticamente.

Anotaciones importantes:

• policies.kyverno.io/description: describí qué hace la política
• policies.kyverno.io/severity: high, medium, low
• kyverno.io/kyverno-version: versión mínima de Kyverno requerida
• kyverno.io/kubernetes-version: versión mínima de K8s

Políticas baseline de seguridad: Pod Security Standards

Las políticas baseline de Kyverno implementan lo que Kubernetes llama Pod Security Standards —un conjunto de buenas prácticas mínimas de seguridad. Incluyen:

Prevenir escalada de privilegios: no permitir que un container tenga `privileged: true` o `allowPrivilegeEscalation: true`. La mayoría de los containers no necesitan eso. Sobre eso hablamos en seguridad en plataformas de código.

Restricción de capabilities peligrosas: bloquear `CAP_SYS_ADMIN`, `CAP_NET_ADMIN`, `CAP_SYS_PTRACE`. Un web server no necesita manipular el kernel.

Evitar mounts de host sensibles: no dejarías montada la filesystem del host en un container de una app, ¿verdad? Kyverno valida que no hagas eso.

No correr como root: fuerza que el container tenga un `runAsNonRoot: true`. Incluso si hay una vulnerabilidad, el atacante está limitado a permisos de ese usuario, no root.

Baseline vs Restricted: Baseline es el piso mínimo —aprueba la mayoría de aplicaciones. Restricted es más estricto y solo deja pasar lo que es minimalmente seguro. Casi nadie usa Restricted; Baseline es el sweet spot.

Monitoreo y auditoría: PolicyReports y gestión de violaciones

Cuando Kyverno evalúa recursos, genera reportes. Son CRDs llamados `PolicyReport` (por namespace) y `ClusterPolicyReport` (cluster-wide).

Un PolicyReport te dice qué recursos pasaron validaciones y cuáles fallaron. Si corrés una política en audit mode, esos reportes te muestran qué se rompería si pasaras a enforce. Es data invaluable para transiciones sin dolor.

Querés ver las violaciones de tu namespace? Fácil:

• kubectl get policyreport -A — todos los reports
• kubectl describe policyreport <nombre> — detalle de cada violación
• kubectl get clusterpolicyreport — policies a nivel cluster

Integrá esto con tu monitoring. Prometheus puede scrapeá las métricas de Kyverno (`kyverno_policy_results_*`). Alertá si la tasa de violaciones sube de repente —probablemente alguien rompió la pipeline. Para más detalles técnicos, mirá alternativas para gestionar repositorios.

RBAC lo complementa: Kyverno no es un reemplazo de RBAC, es un complemento. Vos controlás *quién* puede hacer qué (RBAC). Kyverno controla *qué* se puede hacer (policies). Si un dev no tiene permiso para crear pods privilegiados en RBAC, mucho mejor. Y si por accidente tiene permiso, Kyverno lo bloquea de todas formas.

¿Qué significa para equipos en Latinoamérica?

Si manejás infraestructura en Kubernetes —sea local, en AWS, GCP o donweb.com (que tiene opciones Kubernetes managed)— Kyverno te ahorra auditorías de compliance. En vez de revisar manualmente 500 pods para ver si cumplen standards, Kyverno lo hace automáticamente.

Para equipos chicos, es un guardián invisible. Para equipos grandes con múltiples ambientes, es la diferencia entre caos y gobierno. Y porque es CNCF graduated, la comunidad está madura —no estás apostando a una tecnología joven.

Errores comunes al implementar Kyverno

1. Saltar directo a enforce sin pasar por audit

Los equipos implementan una política y la ponen en enforce. Resultado: todo se rompe, le echan la culpa a Kyverno, lo sacan. Siempre andá con audit dos semanas, mirá qué se rompería, adaptá tu base de datos existente, después enforce. El tooling permite la transición suave, pero tenés que usarlo.

2. No actualizar políticas cuando el contexto cambia

Implementaste una política hace un año que bloquea containers sin recursos limits. Pero ahora usás un Helm chart viejo que no los setea. La política sigue ahí, bloqueando. Revisá tus políticas cada trimestre. Si no tiene sentido, borrala. Si tiene sentido pero la realidad cambió, adaptala.

3. Ignorar los logs de Kyverno

Kyverno deja todo logeado en su namespace (`kyverno`). Si algo no se comporta como esperás, ahí está el por qué. La mayoría de los problemas de “la política no funciona” son configuración, no bugs de Kyverno.

Preguntas Frecuentes

¿Qué pasa si necesito una excepción a una política?

Kyverno tiene `PolicyException` resources. Declarás qué rule, en qué namespace, para qué usuario, necesita una excepción. Eso sí, requiere control y auditoría. No es un “saltá la política cuando quieras”.

¿Cuál es la performance hit de Kyverno?

Minimal. Kyverno corre en el plano de control como un webhook de validación estándar. Agregá típicamente 10-50ms al deployment de un pod. Si tenés clusters donde speedmatters muchísimo (tipo high-frequency trading en Kubernetes, cosa rara), testea. Para cualquier cosa normal, no lo vas a sentir.

¿Puedo usar Kyverno en clusters manejados como EKS o GKE?

Sí, sin problema. Es un Helm chart, se instala normal. No necesita permisos especiales. Funciona igual en managed que en on-premise.

¿Qué diferencia hay entre una ClusterPolicy y una Policy con ClusterRole?

ClusterPolicy aplica a todo el cluster. Policy aplica a un namespace específico. Si querés reglas globales (ej: nunca permitir imágenes sin tag), ClusterPolicy. Si querés una regla solo para tu equipo en un namespace, Policy.

¿Cómo testeo una política antes de deployarla?

Escribí la política en audit mode primero, implementala, mirá los PolicyReports para ver qué violaría si fuera enforce. Herramientas como kyverno test te permiten testear en local antes de commitear. Hay ejemplos en la documentación oficial.

Conclusión

Policy-as-code en Kubernetes no es un lujo, es el baseline en 2026. Kyverno hace que sea simple: YAML, GitOps, integración Argo. Si manejás clusters Kubernetes sin políticas declarativas, estás dejando la puerta abierta a deployments inseguros, no-compliant, o simplemente raros.

El valor real es que las políticas viven en Git, se versionan, se reviewean en PRs, y se sincronizan automáticamente. No es un choque manual; es una guardrail invisible que hace que el governance sea imperceptible para los desarrolladores. Y eso es lo que querés: seguridad que no estorba.

Fuentes

• GitOps policy-as-code: Securing Kubernetes with Argo CD and Kyverno – CNCF Blog
• Kyverno Official Documentation
• Kyverno Policies Repository – Official Policies
• Kubernetes Policy Comparison: Kyverno vs OPA Gatekeeper – Nirmata
• Argo CD + Kyverno Best Practice Policies – Akuity