Kubernetes v1.33 corrige la reutilización de imágenes privadas entre pods

En una publicación del blog de Kubernetes en mayo de 2025, los mantenedores Ben Petersen y Stanislav Láznička describieron un ajuste crítico de seguridad en Kubernetes v1.33. La actualización aborda un problema de hace una década donde los pods podían acceder inadvertidamente a imágenes de contenedores privadas descargadas por otros pods en el mismo nodo sin la autorización adecuada.

Qué ocurrió

Durante más de diez años, los usuarios de Kubernetes se han encontrado con una brecha de seguridad sutil pero significativa relacionada con la configuración imagePullPolicy: IfNotPresent. Esta política está diseñada para optimizar el rendimiento utilizando una imagen almacenada localmente si existe, en lugar de descargarla del registro cada vez. Sin embargo, esta optimización ignoraba previamente las fronteras de autenticación entre diferentes pods programados en el mismo nodo.

El problema principal surgía cuando el Pod A, autorizado con credenciales específicas mediante un imagePullSecret, descargaba una imagen privada en un nodo. Si el Pod B, residente en un namespace diferente y carente de credenciales válidas para ese repositorio privado, era programado posteriormente en el mismo nodo con la política IfNotPresent, el Kubelet le permitía usar la imagen almacenada en caché. El Pod B nunca había sido autorizado para descargar la imagen, pero obtenía acceso simplemente porque las capas binarias ya estaban presentes en el disco. Este comportamiento violaba el principio de menor privilegio y creaba un riesgo potencial de seguridad en la cadena de suministro dentro de los clústeres.

Con el lanzamiento de Kubernetes v1.33, SIG Auth y SIG Node han introducido una corrección para hacer cumplir la verificación de credenciales incluso cuando las imágenes están en caché. El nuevo comportamiento garantiza que un pod solo pueda usar una imagen privada presente localmente si proporciona credenciales que coincidan con las utilizadas durante la descarga inicial. Este cambio cierra la brecha mientras mantiene los beneficios de rendimiento del almacenamiento en caché local para cargas de trabajo autorizadas.

Cómo funciona

La solución se basa en cachés persistentes basados en archivos mantenidos por el Kubelet en cada nodo. Cuando un pod solicita una imagen que no está actualmente en el nodo, el Kubelet registra la intención de descargarla. Luego extrae las credenciales del Secret de Kubernetes referenciado y realiza la descarga desde el registro privado. Tras el éxito, el Kubelet almacena un registro de este evento, incluyendo un hash de las credenciales utilizadas y el identificador del Secret de origen.

Cuando un pod posterior solicita la misma imagen, el Kubelet revisa su caché local. En lugar de servir ciegamente la imagen en caché, compara las credenciales proporcionadas por el nuevo pod contra los registros almacenados. Si el hash de la credencial o el Secret de origen coincide con una descarga exitosa anterior, se concede al pod acceso a la imagen en caché sin volver a descargar datos. Si no hay coincidencia, el Kubelet intenta descargar la imagen desde el registro remoto utilizando las nuevas credenciales, activando el flujo estándar de autorización. Este mecanismo asegura que solo los pods con credenciales válidas y coincidentes puedan reutilizar imágenes privadas en caché.

Detalles clave

• La corrección aborda el issue 18787, una advertencia de seguridad presente en Kubernetes durante más de diez años.
• La función está disponible como versión alpha en Kubernetes v1.33.
• Los usuarios deben habilitar la feature gate KubeletEnsureSecretPulledImages en sus Kubelets para activar el nuevo comportamiento.
• Los pods que usan la misma credencial o Secret de origen no necesitan volver a autenticarse, preservando el rendimiento.
• La política imagePullPolicy: Never ahora también requiere verificación de credenciales para imágenes privadas ya presentes en el nodo.
• Los planes futuros incluyen la integración con tokens de cuentas de servicio proyectados (Projected service account tokens) y la adición de soporte para expiraciones de credenciales.

Por qué importa

Para ingenieros de software y equipos de plataforma, este cambio fortalece el aislamiento del clúster sin requerir cambios operativos drásticos. Anteriormente, muchas organizaciones imponían imagePullPolicy: Always como solución alternativa para asegurar que cada pod realizara una comprobación de autenticación con el registro. Aunque seguro, este enfoque colocaba al registro de imágenes en la ruta crítica para cada inicio, escalado o reinicio de pod, aumentando la latencia y la dependencia de servicios externos. El nuevo mecanismo de verificación permite a los equipos usar IfNotPresent de forma segura, reduciendo la carga del registro y mejorando los tiempos de inicio mientras se mantienen controles estrictos de seguridad.

Esta actualización también simplifica la gestión de clústeres multi-tenant. En entornos donde múltiples equipos comparten nodos, el riesgo de que un equipo acceda accidentalmente a las imágenes privadas de otro equipo se mitiga ahora a nivel del Kubelet. Los ingenieros de plataforma pueden confiar en la infraestructura para hacer cumplir las políticas de acceso en lugar de depender únicamente de políticas de red o controladores de admisión para prevenir el uso no autorizado de imágenes. Este cambio alinea el comportamiento de Kubernetes más estrechamente con las expectativas de los usuarios respecto a la seguridad y el aislamiento.

Qué puede hacer

• Actualice sus clústeres de prueba a Kubernetes v1.33 para evaluar la nueva función.
• Habilite la feature gate KubeletEnsureSecretPulledImages en la configuración de su Kubelet.
• Revise sus configuraciones actuales de imagePullPolicy y considere cambiar de Always a IfNotPresent donde sea apropiado para mejorar el rendimiento.
• Asegúrese de que todos los pods que acceden a imágenes privadas referencien correctamente los imagePullSecrets necesarios.
• Monitoree los logs del Kubelet para detectar cualquier fallo de autenticación durante el despliegue inicial para identificar pods mal configurados.
• Lea KEP-2535 para especificaciones técnicas detalladas y elementos de hoja de ruta futura relacionados con esta función.