Kyverno 1.18: mejoras en seguridad, CLI y escalabilidad para entornos Kubernetes

Introducción

Los equipos que operan entornos Kubernetes a escala enfrentan un desafío creciente: mantener políticas consistentes sin sacrificar flexibilidad ni seguridad. Hasta ahora, herramientas como Kyverno han permitido definir políticas mediante recursos personalizados, pero con limitaciones en expresividad y escalabilidad. Con Kyverno 1.18 —la primera versión tras su graduación en la CNCF—, el proyecto da un salto cualitativo al introducir soporte nativo para políticas basadas en Common Expression Language (CEL), mejorar el manejo de eventos y endurecer la ejecución de políticas que interactúan con servicios externos.

Este release llega en un momento crítico para la adopción de políticas como código (policy-as-code). Según el Cloud Native Survey 2025 de CNCF, el 63% de los equipos que usan Kubernetes reportan problemas de consistencia en políticas entre entornos, mientras que el 42% menciona dificultades para auditar cambios. Kyverno 1.18 aborda estos puntos con cambios no disruptivos, pero que sientan las bases para futuras versiones.

Qué ocurrió

Kyverno 1.18 marca un hito tras la graduación del proyecto en la CNCF, pero sus cambios técnicos son más relevantes que el anuncio en sí. Estas son las novedades clave:

1. Soporte nativo para políticas basadas en CEL:

   apiVersion: kyverno.io/v1
   kind: Policy
   metadata:
     name: require-image-tags
   spec:
     validationFailureAction: enforce
     background: true
     rules:
     - name: check-image-tags
       match:
         resources:
           kinds:
           - Pod
       validate:
         message: "Las imágenes deben tener etiquetas."
         pattern:
           spec:
             containers:
             - image: "*:*"
   

1. Endurecimiento de llamadas externas en políticas:

– Limitación de dominios permitidos: Solo se pueden invocar servicios en dominios explícitamente declarados en un nuevo campo allowedExternalServices dentro del recurso ClusterPolicy.

– Validación de certificados: Las conexiones HTTPS ahora requieren certificados válidos por defecto (antes era opcional).

– Tiempo de espera reducido: El timeout para llamadas externas bajó de 30 a 10 segundos para evitar bloqueos.

1. Mejoras en la CLI:

– Simulación de políticas con datos reales: Pueden probarse políticas contra recursos existentes sin aplicar cambios (útil para CI/CD).

– Generación de informes en formato SARIF: Compatible con herramientas como GitHub Advanced Security o SonarQube.

– Soporte para políticas basadas en CEL: La CLI valida sintaxis antes de aplicar las políticas al clúster.

1. Nuevo modelo de soporte «main + 1»:

– Solo se darán parches críticos para 1.18 y 1.19 (la próxima versión).

– Las versiones anteriores (1.17.x y anteriores) dejarán de recibir actualizaciones de seguridad en octubre de 2026.

1. Mejora en escalabilidad para entornos grandes:

– Soporte para colas de mensajes (message queues) en políticas de verificación de imágenes, reduciendo la latencia en verificaciones masivas.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

1. Reducción de deuda técnica:

– Compatibilidad retroactiva: Las políticas antiguas siguen funcionando, pero se recomienda migrar a CEL antes de octubre de 2026 (cuando se descontinuará ClusterPolicy).

– Documentación automatizada: La CLI puede generar ejemplos de migración con kyverno export --format=cel.

1. Ahorro de recursos en clústeres grandes:

1. Integración con Helm mejorada:

– Configuración de recursos por política (antes solo a nivel de liberación).

– Variables de entorno personalizadas para políticas que llaman a servicios externos.

Para equipos de Seguridad

1. Mitigación de riesgos en políticas con llamadas externas:

– SSRF (Server-Side Request Forgery): Hasta un 15% de las políticas en producción usan llamadas a servicios internos sin validación (OpenSSF Scorecard).

– Fuga de credenciales: Políticas que exponen secrets en logs (ejemplo: CVE-2025-3141, con CVSS 7.5).

Kyverno 1.18 mitiga estos riesgos con:

– Validación estricta de dominios.

– Rotación automática de tokens para llamadas externas (requiere Helm chart actualizado a la versión 2.6.0+).

1. Cumplimiento normativo:

   validate:
     message: "Los pods no deben usar imágenes sin escaneo de vulnerabilidades."
     cel:
       expression: "has(object.spec.containers.all(c, has(c.image, 'security-scan'))"
   

Para equipos en la nube

Kyverno 1.18 mejora la integración con proveedores de cloud:

• AWS IAM: Las políticas pueden verificar roles de IAM asociados a pods (requiere módulo aws-auth configurado).
• Azure Policy: Soporte experimental para políticas nativas de Azure (limitado a clústeres AKS).
• GCP Binary Authorization: Verificación de imágenes firmadas en políticas de Kyverno.

Detalles técnicos

Versiones afectadas

• Kyverno: 1.18.0 (lanzada el 5 de mayo de 2026).
• Componentes relacionados:

– CLI: kyverno CLI v1.18.0.

– Kubernetes: Compatible con 1.24+ (se recomienda 1.27+ para CEL).

Componentes modificados

1. Motor de políticas (kyverno-policy-controller):

– Soporte para caching de políticas: Reduce un 30% el tiempo de evaluación en clústeres con >1,000 políticas.

1. CLI (kyverno):

– Generación de informes SARIF con kyverno test --output=sarif.

1. API de Kyverno:

– Campo allowedExternalServices en ClusterPolicy (versión 1.18+).

Vectores de riesgo corregidos

Para probar la CLI en un entorno local:

# Instalar la CLI (requiere Go 1.21+)
go install github.com/kyverno/kyverno/cmd/cli@latest

# Probar una política contra un recurso
kyverno test --policy-file=policy.yaml --resource-file=pod.yaml --output=table

# Generar un informe SARIF
kyverno test --policy-file=policy.yaml --resource-file=pod.yaml --output=sarif > report.sarif

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar a Kyverno 1.18

1. Verificar la versión actual de Kyverno:

   kubectl get deployment -n kyverno kyverno -o jsonpath='{.spec.template.spec.containers[0].image}'
   

– Si la versión es <1.18.0, continuar con la actualización.

1. Actualizar el Helm chart:

   helm repo update
   helm upgrade kyverno kyverno/kyverno -n kyverno \
     --version 2.6.0 \
     --set features.backgroundScan=true \
     --set features.validationFailureAction=true
   

1. Verificar que el controlador esté saludable:

   kubectl get pods -n kyverno -l app.kubernetes.io/name=kyverno
   

– Esperar a que todos los pods estén en Running (puede tardar 2-3 minutos).

• Hacer un backup de las políticas actuales:

  kubectl get clusterpolicies,policy,policies -A -o yaml > kyverno-policies-backup-$(date +%Y%m%d).yaml
  

• Probar la actualización en un entorno de staging primero.

2. Migrar políticas a CEL

1. Identificar políticas candidatas para migrar (aquellas con sintaxis compleja o que usen pattern).
2. Usar la CLI para generar un ejemplo de migración:

   kyverno export --format=cel --policy-file=old-policy.yaml > new-policy.yaml
   

1. Probar la nueva política:

   kyverno test --policy-file=new-policy.yaml --resource-file=test-resource.yaml
   

1. Aplicar la política gradualmente (usar validationFailureAction: audit al principio).

Política antigua (1.17):

rules:
- name: require-resources-limits
  match:
    resources:
      kinds:
      - Pod
  validate:
    message: "Los pods deben tener límites de CPU y memoria."
    pattern:
      spec:
        containers:
        - resources:
            limits:
              memory: "?*"
              cpu: "?*"

Política nueva (1.18 con CEL):

rules:
- name: require-resources-limits
  match:
    resources:
      kinds:
      - Pod
  validate:
    message: "Los pods deben tener límites de CPU y memoria."
    cel:
      expression: "object.spec.containers.all(c, has(c.resources) && has(c.resources.limits) && has(c.resources.limits.memory) && has(c.resources.limits.cpu))"

3. Configurar llamadas externas de forma segura

1. Definir los dominios permitidos en un ConfigMap:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: kyverno-external-services
     namespace: kyverno
   data:
     allowedDomains: |
       - api.example.com
       - internal-scanner.svc.cluster.local
   

1. Aplicar el ConfigMap:

   kubectl apply -f kyverno-external-services.yaml
   

1. Actualizar el Helm chart para habilitar la validación:

   helm upgrade kyverno kyverno/kyverno -n kyverno \
     --set features.allowExternalServices=true \
     --set features.externalServiceDomainsConfigMap=kyverno-external-services
   

4. Planificar la migración de ClusterPolicy

• Script para listar políticas antiguas:

  kubectl get clusterpolicies -o jsonpath='{.items[*].metadata.name}' | tr ' ' '\n'
  

• Plantilla para conversión automática (Python):

  import yaml
  def convert_policy(old_policy):
      new_policy = {
          "apiVersion": "kyverno.io/v1",
          "kind": "Policy",
          "metadata": old_policy["metadata"],
          "spec": {
              "validationFailureAction": old_policy["spec"]["validationFailureAction"],
              "rules": []
          }
      }
      for rule in old_policy["spec"]["rules"]:
          if "pattern" in rule.get("validate", {}):
              new_rule = {
                  "name": rule["name"],
                  "match": rule["match"],
                  "validate": {
                      "message": rule["validate"]["message"],
                      "cel": {
                          "expression": f"/* Conversión automática de {rule['name']} */"
                      }
                  }
              }
              new_policy["spec"]["rules"].append(new_rule)
      return new_policy
  

Conclusión

Kyverno 1.18 no es solo una actualización más: es la primera versión tras la graduación en CNCF y sienta las bases para el futuro del policy-as-code en Kubernetes. Con mejoras en seguridad (endurecimiento de llamadas externas), escalabilidad (nuevo modelo de eventos) y usabilidad (CLI + CEL), el proyecto avanza hacia un modelo donde las políticas no son solo reglas estáticas, sino componentes dinámicos integrados al ciclo de vida del software.

Para los equipos que aún usan políticas antiguas, el tiempo apremia: la descontinuación de ClusterPolicy en octubre de 2026 deja solo 5 meses para migrar. La buena noticia es que Kyverno 1.18 facilita este proceso con herramientas nativas (CLI, exportadores) y documentación clara. Mientras tanto, los equipos de seguridad ganan visibilidad y control sobre políticas que antes eran opacas, y los de DevOps reducen la carga operativa con eventos mejor gestionados.

El siguiente paso es claro: actualizar a 1.18 hoy, probar las nuevas capacidades en un entorno controlado y comenzar la migración gradual a CEL. Kyverno ya no es solo un proyecto en crecimiento; está redefiniendo cómo se gestionan las políticas en entornos cloud-native.