Por qué Kubernetes 1.35 parece una versión centrada en la seguridad

Las actualizaciones de Kubernetes suelen llegar con un ritmo predecible: un puñado de retoques prácticos, algunas limpiezas internas y quizá una o dos novedades llamativas si las circunstancias acompañan. La versión 1.35 rompe ese esquema. Da la impresión de que los mantenedores de Kubernetes por fin tomaron la lista de tareas de seguridad que llevaba años acumulándose en una esquina y decidieron resolverlo todo de golpe.

La comunidad lo ha notado enseguida. Los ingenieros que analizan el registro de cambios vuelven una y otra vez sobre la misma conclusión: esta versión tiene un impacto enorme para cualquiera que se preocupe por blindar sus clústeres, y genera cierta inquietud entre quienes todavía dependen de comportamientos antiguos.

El repaso de los cambios debatidos en los foros apunta a algo mucho más profundo que una simple actualización incremental. Esta versión eleva el nivel al eliminar comportamientos heredados y cerrar accesos que permanecieron abiertos más tiempo del debido, haciendo que Kubernetes sea más seguro aunque algunas configuraciones sufran durante el proceso.

A continuación detallamos qué cambia realmente y por qué esta entrega destaca como la más orientada a la seguridad en mucho tiempo.

Cambios de seguridad que podrían complicarte el día

Una actualización de clúster no asusta hasta que aparece la frase «esto puede romper configuraciones», y la 1.35 incluye varios avisos de ese tipo.

1. Adiós a cgroup v1 (#5573)

Este cambio se venía preparando desde hace tiempo y no pilla por sorpresa a nadie, pero el abandono oficial de cgroup v1 por parte de Kubernetes es uno de esos hitos que impactan en producción con más fuerza de la prevista.

Algunas cargas de trabajo han dependido durante años de particularidades de v1 sin que nadie se percatara. Las opiniones en la comunidad combinan el alivio de «ya era hora» con el temor de «si esto rompe mi entorno, cambio de plataforma». Supone un salto de compatibilidad importante y los equipos son conscientes de ello.

2. Obligatoriedad de secretos para descargar imágenes (#2535)

Esta modificación endurece el modo en que Kubernetes gestiona las imágenes que requieren secretos para su descarga. Si tu clúster tenía configuraciones ambiguas o incoherentes en este punto, el nuevo mecanismo las señalará de inmediato.

Tiene todo el sentido desde la perspectiva de la seguridad, ya que permitir la descarga de imágenes sin las comprobaciones de secretos adecuadas constituía un punto ciego arriesgado. También es el típico cambio que saca a la luz esquinas olvidadas en los pipelines de CI/CD.

3. Transición de SPDY a WebSockets (#4006)

SPDY se ha mantenido en el proyecto más tiempo del esperado, y Kubernetes traslada por fin sus dependencias pendientes hacia WebSockets.

Este cambio no debería hacer caer los clústeres, pero obliga a algunos operadores a revisar herramientas, proxies y contenedores sidecar antiguos que todavía esperaban SPDY. WebSockets aporta un enfoque más moderno y seguro, aunque, como ocurre en la mayoría de las transiciones de protocolos, provocará roces hasta que todo el ecosistema se adapte.

4. Validación reforzada de certificados de Kubelet (#4872)

Es una novedad menos llamativa pero probablemente una de las más relevantes. El servidor de la API de Kubernetes refuerza ahora la validación de los certificados con los que Kubelet presta servicio.

En la práctica, esto reduce las asunciones erróneas sobre la identidad, elimina vacíos en nodos mal configurados y corta posibles vías de ataque por suplantación. Este tipo de blindaje demuestra su valor con el paso del tiempo, en especial en clústeres grandes donde la gestión de certificados suele desajustarse con los meses.

Las nuevas funciones de seguridad que marcan la diferencia

Más allá de los cambios que rompen compatibilidad, Kubernetes 1.35 incorpora varias mejoras diseñadas para llevar la plataforma hacia un modelo más moderno y blindado.

1. Suplantación restringida (#5284)

La suplantación de identidad siempre ha sido un arma de doble filo. Es una capacidad imprescindible para herramientas, operadores y tareas de automatización, pero también representa uno de los permisos más delicados que se pueden conceder dentro de un clúster.

La nueva función de suplantación restringida permite acotar quién o qué puede suplantar a determinadas cuentas de servicio o grupos de usuarios. Es el equivalente a poner cinturones de seguridad a una función que debería haberlos tenido desde el primer día.

2. Flagz para componentes de Kubernetes (#4828)

En pocas palabras: los componentes de Kubernetes ahora pueden exponer sus flags de ejecución de forma estructurada y transparente.

Esto resulta clave para la seguridad porque los errores de configuración suelen ocultarse en los flags, y poder inspeccionarlos con claridad es una de las maneras más rápidas de detectar desviaciones, diagnosticar comportamientos anómalos o descubrir parámetros que no deberían estar activos. En clústeres complejos, la visibilidad supone la mitad del trabajo.

3. Permitir que los pods con HostNetwork usen user namespaces (#5607)

Este avance es significativo para entornos que buscan aislar cargas de trabajo con mayor firmeza. Los user namespaces eran una petición histórica para reforzar la seguridad multinquilino, y permitir que los pods con HostNetwork aprovechen ese aislamiento ayuda a reducir el radio de impacto de las cargas con privilegios.

No funcionará como un escudo mágico, pero supone un avance tangible, y los avances son escasos cuando se trata de privilegios a nivel de red.

4. Consentimiento del controlador CSI para tokens de SA mediante secretos (#5538)

Históricamente, los controladores CSI recibían tokens de cuentas de servicio tanto si los necesitaban como si no, con los riesgos evidentes que eso conllevaba. La versión 1.35 invierte esa lógica: los controladores deben solicitar el acceso explícitamente, consolidando el principio de mínimo privilegio por defecto.

Funciones activadas por defecto y su impacto en la seguridad

Algunas mejoras llevaban bastante tiempo detrás de feature gates, esperando el momento en que Kubernetes considerase que el ecosistema estaba listo. La versión 1.35 activa varias de ellas de forma predeterminada.

1. Certificados para pods (#4317)

La automatización de certificados dentro de Kubernetes solía parecerse a manipular cables con corriente. Los certificados para pods convierten la identidad en un elemento de primer nivel, más fácil de automatizar y más difícil de utilizar de forma incorrecta.

Muchos administradores esperaban que esto saliera de la fase experimental; su promoción en 1.35 refleja una madurez evidente en la identidad de las cargas de trabajo.

2. User namespaces para pods (#127)

Esto forma parte de un esfuerzo más amplio por reducir la brecha entre el usuario root dentro de un contenedor y el root del host. Los user namespaces han sido la pieza ausente durante años, y activarlos por defecto sitúa a Kubernetes en un punto de partida más seguro para todas las cargas de trabajo, incluso aquellas que no se diseñaron con un aislamiento estricto en mente.

3. Artefactos e imágenes OCI como VolumeSource (#4639)

En sentido estricto no es una función de seguridad pura, pero tiene consecuencias directas sobre ella. Permitir que los volúmenes tomen su origen en artefactos OCI abre vías más limpias y homogéneas para distribuir contenido de solo lectura, lo que reduce los sistemas hechos a medida, los casos límite extraños y las oportunidades de introducir elementos no deseados en los montajes de volumen.

4. Separación de preferencias de usuario de kubectl y configuraciones de clúster (#3104)

Un ajuste pequeño pero relevante. Mezclar las preferencias de usuario con las configuraciones del clúster facilitaba que errores o valores por defecto inadecuados se filtraran hacia producción. Al separarlos, Kubernetes mitiga el riesgo de equivocaciones involuntarias durante los despliegues.

5. Eliminación de la dependencia de Gogo Protobuf (#5589)

La seguridad y las bibliotecas de serialización tienen una relación compleja. Prescindir de dependencias antiguas, en particular aquellas con un largo historial y garantías dispares, siempre supone una mejora.

6. Configuración estructurada de autenticación (#3331)

Esta mejora pone orden en la definición de los parámetros de autenticación, reduciendo la probabilidad de cometer errores y facilitando su detección. Una configuración más clara se traduce en menos sorpresas.

7. Control granular de SupplementalGroups (#3619)

RBAC no es el único ámbito donde importa el control de acceso. Los SupplementalGroups condicionan los permisos de archivos dentro de los pods, y un control más fino permite a los administradores ajustar el aislamiento de las cargas según sus modelos de seguridad con mayor precisión.

8. Directorio de configuración drop-in para Kubelet (#3983)

Puede parecer un detalle secundario hasta que pasas un fin de semana rastreando un flag mal configurado. Un directorio de configuración drop-in adecuado garantiza anulaciones predecibles, actualizaciones consistentes y menos modificaciones accidentales. La seguridad agradece la previsibilidad, y esta mejora aporta justo eso.

Por qué 1.35 marca un punto de inflexión

La sensación general en torno a esta versión es que Kubernetes entra en una etapa donde la seguridad deja de ser un tema secundario para ocupar el lugar central.

Muchos administradores reclamaban esta evolución. Kubernetes ha madurado y los cambios sencillos ya quedaron atrás. La plataforma está probada en batalla, ampliamente desplegada y expuesta a amenazas modernas que ni siquiera existían cuando arrancó el proyecto. La versión 1.35 responde a esa realidad.

Cierra accesos antiguos, sustituye premisas obsoletas y otorga más control a los administradores que necesitan una protección estricta. Incluso las modificaciones con riesgo de romper entornos en producción persiguen un objetivo claro: valores por defecto más seguros, mejor aislamiento y menos rutas por las que los problemas puedan pasar inadvertidos.

¿Es una versión perfecta? Desde luego que no. Cualquier lanzamiento que modifique tantas áreas delicadas causará algún dolor de cabeza. Habrá quien actualice y se encuentre con fallos imprevistos. Forma parte de operar Kubernetes a gran escala, donde las concesiones técnicas son constantes.

En conjunto, Kubernetes 1.35 asume con franqueza el futuro de la plataforma. Nos dirigimos hacia un entorno donde las cargas de trabajo exigen una identidad sólida, los contenedores requieren un aislamiento real y los equipos de infraestructura no pueden permitirse inercias del pasado con riesgos invisibles. Esta versión reconoce ese cambio y lo abraza de lleno.