En el ecosistema de Kubernetes, la seguridad y la gobernanza son aspectos clave que requieren atención continua. Aunque Kubernetes ofrece algunas características de seguridad listas para usar (OOTB) como la Admisión de Seguridad de Pods (PSA), estas pueden no ser suficientes para entornos complejos con requisitos de cumplimiento variables. Aquí es donde Kyverno entra en juego, proporcionando una solución poderosa pero flexible para gestionar y hacer cumplir políticas en todo tu clúster.
En esta publicación, exploraremos las diferencias clave entre Kyverno y PSA, explicaremos cómo se puede usar Kyverno en diferentes casos de uso y te mostraremos cómo instalar y desplegar políticas con él. Aunque la creación de políticas personalizadas se cubrirá en una publicación separada, haremos referencia a algunas políticas preconstruidas que puedes usar de inmediato.
¿Qué es Kyverno?
Kyverno es un motor de políticas para Kubernetes que permite validar, mutar y generar recursos del clúster con políticas escritas en YAML plano — sin aprender ningún lenguaje nuevo. Funciona como admission controller: cuando alguien aplica un recurso, Kyverno intercepta la petición y la permite, la rechaza, la corrige al vuelo o crea recursos adicionales, según las reglas que hayas definido.
Usos típicos: exigir que todo pod declare límites de recursos, bloquear imágenes de registries no confiables, requerir etiquetas en los namespaces, inyectar automáticamente una NetworkPolicy en cada namespace nuevo, o verificar firmas de imágenes antes de admitir un workload. La versión actual es Kyverno v1.18.2 (julio de 2026).
Kyverno vs OPA Gatekeeper: ¿qué motor de políticas elegir?
La versión corta: elige Kyverno si tus políticas son solo de Kubernetes y las quieres en YAML; elige OPA Gatekeeper si necesitas máxima expresividad o reutilizar el mismo lenguaje de políticas fuera de Kubernetes. Tras años de convergencia, la decisión rara vez es de capacidades.
| Kyverno | OPA Gatekeeper | |
|---|---|---|
| Lenguaje | YAML (y CEL); nada nuevo que aprender | Rego, vía ConstraintTemplates |
| Curva de aprendizaje | Baja | Alta — Rego es un lenguaje real |
| Validar | ✅ | ✅ su punto más fuerte |
| Mutar | ✅ nativo | ✅ añadido después, fuera de Rego |
| Generar recursos | ✅ nativo | ❌ |
| Ámbito | Solo Kubernetes | Kubernetes + APIs, microservicios, Terraform |
| Madurez CNCF | Graduated | Graduated (parte de OPA) |
| Versión actual | v1.18.2 (jul 2026) | v3.23.0 (jul 2026) |
Hay una tercera opción que no existía al inicio de este debate: ValidatingAdmissionPolicy con CEL, nativa de Kubernetes y sin componentes extra. Si la regla se puede expresar en CEL, es la primera a considerar; pero CEL no puede hacer llamadas externas ni mantener estado, así que la verificación de firmas, los lookups entre recursos, la mutación y la generación siguen siendo territorio de Kyverno o Gatekeeper. Kyverno es un proyecto CNCF Graduated creado por Nirmata, con soporte comercial disponible de varios proveedores; el proyecto open source es Apache-2.0 sin funcionalidad recortada.
¿Qué es la Admisión de Seguridad de Pods (PSA)?
Kubernetes introdujo Admisión de Seguridad de Pods (PSA) como un reemplazo para la ahora obsoleta Política de Seguridad de Pods (PSP). PSA se centra en hacer cumplir tres niveles de seguridad predefinidos: Privilegiado, Básico y Restringido. Estos niveles controlan qué pods pueden ejecutarse en un espacio de nombres según sus configuraciones de contexto de seguridad.
- Privilegiado: Restricciones mínimas, permitiendo contenedores privilegiados y acceso al host.
- Básico: Aplica restricciones estándar, no permitiendo contenedores privilegiados y limitando el acceso al host.
- Restringido: El nivel más estricto, asegurando configuraciones seguras por defecto y aplicando las mejores prácticas para ejecutar contenedores.
Si bien PSA es efectivo para requisitos de seguridad básicos, carece de flexibilidad al aplicar políticas personalizadas o de grano fino. Tenemos un artículo completo que cubre este tema que puedes leer aquí.
Kyverno vs. PSA: Diferencias Clave
Kyverno va más allá de las capacidades de PSA al ofrecer un control más granular y flexibilidad. Así es como se compara:
- Tipos de Políticas: Mientras que PSA se centra únicamente en la seguridad, Kyverno permite la creación de políticas para validación, mutación y generación de recursos. Esto significa que puedes modificar o generar nuevos recursos, no solo aplicar reglas de seguridad.
- Personalización: Kyverno admite políticas personalizadas que pueden hacer cumplir los requisitos de cumplimiento de tu organización. Puedes escribir políticas que gobiernen tipos de recursos específicos, como asegurar que todos los despliegues tengan ciertas etiquetas o que las imágenes de los contenedores provengan de un registro de confianza.
- Política como Código: Las políticas de Kyverno están escritas en YAML, lo que permite una fácil integración con pipelines de CI/CD y flujos de trabajo de GitOps. Esto hace que la gestión de políticas sea declarativa y controlada por versiones, lo cual no es el caso con PSA.
- Auditoría e Informes: Con Kyverno, puedes generar registros de auditoría detallados e informes sobre violaciones de políticas, dando a los administradores una visión clara de cómo se aplican las políticas y dónde ocurren las violaciones. PSA carece de esta capacidad de informes integrada.
- Aplicación y Mutación: Mientras que PSA principalmente aplica restricciones en los pods, Kyverno permite no solo la validación de configuraciones sino también la modificación de recursos (mutación) cuando sea necesario. Esto añade una capa adicional de flexibilidad, como agregar automáticamente anotaciones o etiquetas.
Cuándo Usar Kyverno en Lugar de PSA
Si bien PSA podría ser suficiente para entornos más simples, Kyverno se convierte en una herramienta valiosa en escenarios que requieren:
- Reglas de Cumplimiento Personalizadas: Por ejemplo, hacer cumplir que todos los contenedores usen una imagen base específica o restringir capacidades específicas de contenedores en diferentes entornos.
- Integraciones CI/CD: Kyverno puede integrarse en tus pipelines de CI/CD, asegurando que los recursos cumplan con las políticas organizacionales antes de ser desplegados.
- Gobernanza Compleja: Al gestionar grandes clústeres con múltiples equipos, la jerarquía de políticas y el alcance de Kyverno permiten un control más fino sobre quién puede desplegar qué y cómo se configuran los recursos.
Si tu organización necesita una solución de seguridad más robusta y flexible, Kyverno es una mejor opción en comparación con el enfoque más genérico de PSA.
Instalando Kyverno
Para comenzar a usar Kyverno, necesitarás instalarlo en tu clúster de Kubernetes. Este es un proceso sencillo usando Helm, lo que facilita su gestión y actualización.
Instalación Paso a Paso
Agrega el repositorio Helm de Kyverno:
helm repo add kyverno https://kyverno.github.io/kyverno/Actualiza los repositorios de Helm:
helm repo updateInstala Kyverno en tu clúster de Kubernetes:
helm install kyverno kyverno/kyverno --namespace kyverno --create-namespaceVerifica la instalación:
kubectl get pods -n kyvernoDespués de la instalación, Kyverno comenzará a aplicar políticas en todo tu clúster, pero necesitarás desplegar algunas políticas para comenzar.
Instalar la CLI de Kyverno
Además del controller en el clúster, Kyverno tiene una CLI para probar políticas antes de que lleguen a producción — es lo que convierte las políticas en algo revisable en una pull request:
# macOS / Linux (Homebrew)
brew install kyverno
# Como plugin de kubectl (Krew)
kubectl krew install kyverno
# Probar una política contra manifiestos, sin clúster
kyverno apply ./policies/ --resource ./manifests/
# Ejecutar la suite de tests declarativos
kyverno test ./policies/Antes de escribir nada propio, revisa la biblioteca oficial de políticas: cientos de políticas listas por categoría (Pod Security Standards, buenas prácticas, multi-tenancy, verificación de imágenes). El punto de partida realista es adoptar el set de PSS en modo audit, ver qué incumple ya tu clúster, y solo entonces escribir reglas propias. La integración en CI está cubierta paso a paso en integrar Kyverno CLI en pipelines CI/CD con GitHub Actions.
Desplegando Políticas con Kyverno
Las políticas de Kyverno están escritas en YAML, al igual que los recursos de Kubernetes, lo que las hace fáciles de leer y gestionar. Puedes encontrar varias políticas listas para usar en la Biblioteca de Políticas de Kyverno, o crear las tuyas propias para que se ajusten a tus requisitos.
A continuación, un ejemplo de una política de validación simple que asegura que todos los pods usen imágenes de contenedores de confianza de un registro específico:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-trusted-registry
spec:
validationFailureAction: enforce
rules:
- name: check-registry
match:
resources:
kinds:
- Pod
validate:
message: "Solo se permiten imágenes de 'myregistry.com'."
pattern:
spec:
containers:
- image: "myregistry.com/*"Esta política bloqueará automáticamente el despliegue de cualquier pod que use una imagen de un registro diferente a myregistry.com.
Aplicando la Política
Para aplicar la política anterior, guárdala en un archivo YAML (por ejemplo, trusted-registry-policy.yaml) y ejecuta el siguiente comando:
kubectl apply -f trusted-registry-policy.yamlUna vez aplicada, Kyverno hará cumplir esta política en todo tu clúster.
Visualizando Informes de Políticas de Kyverno
Kyverno genera informes detallados sobre violaciones de políticas, que son útiles para auditorías y seguimiento del cumplimiento de políticas. Para verificar los informes, puedes usar los siguientes comandos:
Lista todos los informes de políticas de Kyverno:
kubectl get clusterpolicyreportDescribe un informe de política específico para obtener más detalles:
kubectl describe clusterpolicyreport <report-name>Estos informes pueden integrarse en tus herramientas de monitoreo para activar alertas cuando ocurran violaciones críticas.
Preguntas frecuentes
¿Para qué sirve Kyverno?
Kyverno es un motor de políticas de Kubernetes que valida, muta y genera recursos del clúster. Usos típicos: exigir límites de recursos en los pods, bloquear imágenes de registries no confiables, requerir etiquetas en namespaces, generar automáticamente NetworkPolicies o ConfigMaps en namespaces nuevos, y verificar firmas de imágenes antes de admitir un workload. Las políticas se escriben en YAML y se aplican como objetos de Kubernetes.
¿Kyverno u OPA Gatekeeper?
Usa Kyverno si tus políticas solo apuntan a Kubernetes y las quieres en YAML sin aprender un lenguaje nuevo — además muta y genera recursos de forma nativa. Usa OPA Gatekeeper si necesitas lógica muy expresiva o reutilizar las mismas políticas Rego fuera de Kubernetes. Ambos son CNCF Graduated y han convergido en capacidades para el caso de admisión.
¿Kyverno es gratis? ¿Qué empresa está detrás?
El proyecto es open source bajo Apache-2.0 y es CNCF Graduated, así que no lo controla un único vendor. Lo creó Nirmata, que sigue siendo el mayor contribuidor y ofrece soporte comercial y LTS; también dan soporte comercial Giant Swarm, InfraCloud, BlakYaks y Kodekloud.
¿Sigo necesitando Kyverno con ValidatingAdmissionPolicy?
Para reglas simples, a menudo no: ValidatingAdmissionPolicy con CEL viene integrada en Kubernetes y no necesita componentes extra. Pero CEL no puede hacer llamadas externas ni mantener estado, y solo valida. La verificación de firmas, los lookups entre recursos, la mutación y la generación siguen requiriendo Kyverno o Gatekeeper. Muchos clústeres usan ambas.
¿Qué diferencia hay entre Kyverno y Pod Security Admission?
PSA viene integrada en Kubernetes y aplica los tres perfiles fijos de Pod Security Standards a nivel de namespace; es simple pero no extensible. Kyverno es un motor general: puede reproducir los perfiles PSS y además añadir reglas propias, mutación y generación, sobre cualquier tipo de recurso, no solo pods.
Conclusión
Kyverno ofrece una forma flexible y poderosa de hacer cumplir políticas en Kubernetes, convirtiéndose en una herramienta esencial para organizaciones que necesitan más que las capacidades básicas proporcionadas por PSA. Ya sea que necesites asegurar el cumplimiento con estándares de seguridad internos, automatizar modificaciones de recursos o integrar políticas en pipelines de CI/CD, el extenso conjunto de características de Kyverno lo convierte en una opción preferida para la gobernanza de Kubernetes.
Por ahora, comienza con las políticas listas para usar disponibles en la biblioteca de Kyverno. En publicaciones futuras, profundizaremos en la creación de políticas personalizadas adaptadas a tus necesidades específicas.
📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.















