Kubernetes v1.36: más seguridad por defecto y soporte nativo para cargas de trabajo de IA

Introducción

En clusters productivos donde conviven cargas de trabajo tradicionales con nodos GPU para IA/ML, la gestión de permisos y la asignación de recursos suele ser un dolor de cabeza recurrente. La versión v1.36 de Kubernetes, lanzada en mayo de 2026, llega para resolver estos problemas no solo con parches de seguridad, sino con cambios profundos en los defaults que reducen la complejidad operativa. Lo más relevante: User Namespaces ya es GA, las políticas de admisión mutantes usan CEL sin webhooks externos, y el modelo de asignación de GPUs basado en plugins enteros se reemplaza por un sistema basado en particiones y recursos consumibles.

Esta release no introduce mecanismos radicalmente nuevos, sino que consolida prácticas que equipos de DevOps y SRE ya venían usando en producción para mitigar riesgos de seguridad y escalabilidad. Según el blog oficial del proyecto, participaron 106 empresas y 491 individuos, lo que refleja el peso de estos cambios en la comunidad.

Qué ocurrió

Kubernetes v1.36 (nombre en clave Haru) contiene 70 mejoras en total:

• 18 graduadas a Stable (General Availability),
• 25 en Beta,
• 25 en Alpha.

El foco principal es triple:

1. Seguridad hardening: User Namespaces, SELinux Volume Labeling, autorización fina para kubelet, políticas de admisión mutantes con CEL nativo.
2. Soporte para IA/ML: DRA (Dynamic Resource Allocation) con particionamiento de GPUs, preemptión por grupos de pods, y Gang Scheduling en Beta.
3. Escalabilidad de API: sharded list and watch streams en Alpha para clusters con miles de objetos.

Dos cambios destacan por su impacto inmediato:

User Namespaces en GA

Este feature mapea el usuario root dentro del contenedor a un usuario no privilegiado en el host, de modo que, si un proceso escapa del contenedor, no obtenga acceso administrativo al nodo. La vulnerabilidad de escape de contenedores es uno de los vectores más explotados en entornos cloud: según el informe CVE-2024-21626, permite escalada de privilegios locales en kernels Linux 5.15 a 6.6. User Namespaces mitiga este riesgo al nivel del runtime, sin depender de parches del kernel.

Políticas de admisión mutantes con CEL nativo

Las Mutating Admission Policies permiten definir lógica de mutación como un objeto Kubernetes nativo usando Common Expression Language (CEL). Hasta ahora, esto requería un webhook externo (como OPA o Kyverno), lo que agregaba latencia y complejidad operativa. En v1.36, este feature llega a GA y reduce la latencia de admisión de ~100ms a ~10ms en clusters con alta carga de pods, según mediciones de Kloia.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

• Menor complejidad operativa: Eliminación de webhooks personalizados para políticas de admisión mutantes.
• Menor riesgo de escape de contenedores: User Namespaces aplica incluso en clusters donde no se puede actualizar el kernel a 6.8+.
• Escalabilidad en APIs: Los sharded list and watch streams permiten manejar clusters con más de 50,000 pods por nodo sin saturación de la API server, según benchmarks internos del SIG API Machinery.

Para equipos de Cloud e Infraestructura

• Asignación de GPUs más eficiente: El modelo de Device Plugins entero (basado en asignar GPUs completas) se reemplaza por:

– DRA Consumable Capacity: Los pods declaran recursos consumibles (ej: «necesito 10GB de VRAM y 2 núcleos de CPU»), en lugar de pedir «1 GPU».

– DRA Device Taints and Tolerations: Los nodos pueden tainear GPUs dañadas o en mantenimiento, y el scheduler evita asignar pods a ellas.

Esto reduce el GPU fragmentation (pérdida de recursos no utilizados) del 30% al 8% en clusters con cargas de AI/ML, según datos de VMware Cloud Foundation.

Para equipos de Seguridad

• Autorización fina para kubelet: Hasta ahora, herramientas de monitoreo (como Prometheus) necesitaban el permiso nodes/proxy para acceder a métricas del kubelet. En v1.36, la feature Fine-Grained Kubelet API Authorization (disponible en GA) permite definir políticas como:

  apiVersion: v1
  kind: KubeletAuthorization
  metadata:
    name: prometheus-kubelet-access
  spec:
    nodeSelector:
      kubernetes.io/arch: amd64
    allowedAPIs:
      - /metrics
      - /stats/summary
    users:
      - system:serviceaccount:monitoring:prometheus-kubelet
  

Esto reduce el blast radius de un compromiso del servicio de monitoreo.

• SELinux Volume Labeling: En clusters con SELinux enforcing, el relabeling recursivo de volúmenes al montar pods podía agregar hasta 5 segundos de latencia por pod. Con la nueva opción --mount-context, el label se aplica al momento del montaje, eliminando este overhead.

Detalles técnicos

User Namespaces (GA)

• Versión afectada: v1.36 y posteriores.
• Requisitos:

– CONFIG_USER_NS=y en el kernel (habilitado por defecto en kernels modernos).

– En kubelet, agregar la flag:

    --feature-gates=UserNamespacesSupport=true
    

(habilitado por defecto en v1.36).

• Vector de riesgo mitigado: Escape de contenedores → escalada de privilegios locales (ej: CVE-2024-21626).
• Benchmark: En un cluster con 500 pods, la latencia de inicio de pods con User Namespaces activado es ~80ms mayor que sin él, pero compensa con seguridad.

Mutating Admission Policies con CEL (GA)

• Versión: v1.36.
• Sintaxis de ejemplo:

  apiVersion: admissionregistration.k8s.io/v1
  kind: MutatingWebhookConfiguration
  metadata:
    name: example-mutator
  webhooks:
  - name: example.mutator.io
    rules:
      - operations: ["CREATE", "UPDATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    clientConfig:
      service:
        name: mutator-service
        namespace: default
        path: "/mutate"
    admissionReviewVersions: ["v1"]
    sideEffects: None
    timeoutSeconds: 1
  

Se reemplaza por:

  apiVersion: admissionregistration.k8s.io/v1
  kind: MutatingAdmissionPolicy
  metadata:
    name: example-cel-mutator
  spec:
    policy:
      type: "ValidatingAdmissionPolicy"
      validations:
        - expression: "object.spec.containers.all(c, c.resources.requests.cpu != null)"
          message: "Todos los contenedores deben definir requests de CPU"
  

• Rendimiento: Reducción del 90% en latencia frente a webhooks externos, según pruebas de Kloia con 10,000 pods por minuto.

DRA y asignación de GPUs (Beta/GA)

• Cambios clave:

     apiVersion: resource.k8s.io/v1alpha3
     kind: ResourceSlice
     metadata:
       name: a100-40gb
     spec:
       nodeName: gpu-node-1
       devices:
         - name: "gpu-0"
           capacity: {"example.com/gpu": "10"}
           allocatable: {"example.com/gpu": "4"}
           type: "Partitionable"
     

2. Consumable Capacity: Los pods pueden pedir recursos granulares:

     resources:
       requests:
         example.com/gpu: "2.5"  # 2.5 particiones de 10GB VRAM
       limits:
         example.com/gpu: "2.5"
     

3. Device Taints: Los nodos pueden marcar GPUs dañadas:

     taints:
       - key: "example.com/gpu-faulty"
         value: "true"
         effect: "NoSchedule"
     

• Impacto en clusters de IA: Reducción del 40% en desperdicio de GPUs en un cluster con 120 GPUs A100, según datos de ScaleOps.

Fine-Grained Kubelet API Authorization (GA)

• Versión: v1.36.
• API afectada: /proxy, /metrics, /stats.
• Ejemplo de política:

  apiVersion: kubelet.config.k8s.io/v1beta1
  kind: KubeletConfiguration
  auth:
    fineGrainedKubeletAuthorization:
      enabled: true
      policies:
        - name: "prometheus-readonly"
          users: ["system:serviceaccount:monitoring:prometheus"]
          verbs: ["get", "list"]
          paths: ["/metrics", "/stats/summary"]
  

• Riesgo mitigado: Un compromiso de Prometheus ya no puede ejecutar comandos en el kubelet (evita escalada a nodos).

SELinux Volume Labeling (GA)

• Versión: v1.36.
• Problema resuelto: En clusters con SELinux enforcing, cada pod monta volúmenes con relabeling recursivo, lo que agregaba ~5 segundos por pod en clusters con 1000 pods.
• Solución: Usar --mount-context al montar:

  mount -o context=system_u:object_r:container_file_t:s0 /dev/sdb1 /var/lib/kubelet/pods/...
  

Esto aplica el label al momento del montaje, eliminando el overhead.

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

Pasos inmediatos (para clusters en producción)

1. Habilitar User Namespaces (si no está activo):

   # En el kubelet (versión ≥1.36)
   sudo systemctl edit kubelet.service
   

Agregar:

   [Service]
   ExecStart=
   ExecStart=/usr/local/bin/kubelet \
     --feature-gates=UserNamespacesSupport=true \
     # ... otras flags ...
   

Reiniciar el kubelet:

   sudo systemctl restart kubelet
   

   kubectl get nodes -o json | jq '.items[].status.conditions[] | select(.type=="UserNamespacesSupported")'
   

1. Migrar políticas de admisión mutantes a CEL nativo:

– Reemplazar configuraciones como:

     apiVersion: admissionregistration.k8s.io/v1
     kind: MutatingWebhookConfiguration
     

por:

     apiVersion: admissionregistration.k8s.io/v1
     kind: MutatingAdmissionPolicy
     

– Validar: Usar kubectl describe mutatingadmissionpolicy <nombre> para confirmar que no hay errores en las expresiones CEL.

1. Actualizar a DRA para GPUs (si usas GPUs en clusters de IA/ML):

     --feature-gates=DynamicResourceAllocation=true,TopologyAwareDynamicResourceAllocation=true
     

– Verificar recursos disponibles:

     kubectl get resourceslices
     

– Ajustar requests/limits en tus Pods y Deployments:

     resources:
       requests:
         example.com/gpu: "0.5"  # 50% de una partición
       limits:
         example.com/gpu: "0.5"
     

1. Aplicar Fine-Grained Kubelet API Authorization:

     auth:
       fineGrainedKubeletAuthorization:
         enabled: true
     

– Auditar permisos de herramientas como Prometheus, Datadog, o Grafana:

     kubectl get clusterrolebinding -o json | jq '.items[] | select(.subjects[].name | contains("prometheus"))'
     

1. Optimizar SELinux en clusters enforcing:

     apiVersion: storage.k8s.io/v1
     kind: StorageClass
     metadata:
       name: fast-ssd
     provisioner: kubernetes.io/gce-pd
     parameters:
       fsType: ext4
       mountOptions: "context=system_u:object_r:container_file_t:s0"
     

– Medir impacto: Comparar tiempos de inicio de pods antes/después con kubectl get pods -w.

1. Monitorear cambios en el scheduler:

     kubectl get pods -n ai-workloads -l app=distributed-training
     

– Logs del scheduler:

     kubectl logs -n kube-system kube-scheduler-<pod> | grep "Gang"
     

Conclusión

Kubernetes v1.36 no es una release disruptiva, sino una consolidación de prácticas que equipos de DevOps ya aplicaban en producción. Los cambios más relevantes —User Namespaces, políticas de admisión con CEL nativo, y DRA para GPUs— reducen la complejidad operativa, mejoran la seguridad por defecto, y optimizan recursos en clusters con cargas de IA/ML.

Para equipos que ya usan estos patrones en producción, la actualización a v1.36 es recomendada pero no urgente. Sin embargo, para clusters nuevos o con alta rotación de pods, los beneficios en seguridad y escalabilidad justifican la migración inmediata. El mayor desafío será migrar políticas de admisión mutantes desde webhooks externos a CEL nativo, pero la reducción en latencia y la eliminación de dependencias externas lo hacen un cambio con ROI claro.

Fuentes

• InfoQ: Kubernetes v1.36 Released — Security Defaults Tighten as AI Workload Support Matures
• Kloia: Kubernetes 1.36 — What’s New?
• VMware Cloud Foundation: Dynamic Resource Allocation in Kubernetes 1.36
• ScaleOps: Kubernetes 1.36 for AI/ML Workloads
• Palark: Kubernetes 1.36 — Workload-Aware Preemption