Anuncio de Istio 1.29.9
Parche de Istio 1.29.9.
Esta versión contiene correcciones de seguridad. Estas notas de versión describen las diferencias entre Istio 1.29.8 e Istio 1.29.9. Esta es la última versión de 1.29, ya que 1.29 alcanzó el fin de su vida útil el 15 de octubre de 2026. Te recomendamos actualizar a una versión compatible.
ANTES DE ACTUALIZAR
Cosas que debes saber y preparar antes de actualizar.
DESCARGAR
Descarga e instala esta versión.
DOCUMENTACIÓN
Visita la documentación de esta versión.
CAMBIOS EN EL CÓDIGO FUENTE
Inspecciona el conjunto completo de cambios en el código fuente.
Actualización de seguridad
Para más información, consulta ISTIO-SECURITY-2026-007.
CVEs de Envoy
- GHSA-8vc2-jrm4-835w: (puntuación CVSS 7.5): Corregida una terminación anormal remota sin autenticación en el filtro HTTP OAuth2 ante una solicitud CONNECT sin cabecera
:path. - GHSA-47vj-9r25-wv5j: (puntuación CVSS 6.5): Corregida una terminación anormal en el filtro HTTP
api_key_authante una solicitud CONNECT sin cabecera:path. - CVE-2026-111497: Se corrigió una vulnerabilidad en la biblioteca de compresión Brotli usada por Envoy. Los usuarios que habiliten la descompresión Brotli, por ejemplo con un
EnvoyFilter, deben actualizar.
CVEs de Istio
- GHSA-w44g-8m76-8gc5 (puntuación CVSS 7.4, Alta): Las reglas de método de
AuthorizationPolicyse eluden sobre HTTP/2 al cambiar entre mayúsculas y minúsculas en el método. Crédito: Esta vulnerabilidad fue descubierta y reportada por izzysec. - GHSA-7p2q-4xvg-vxc6 (puntuación CVSS 7.7, Alta): istiod termina de forma anormal en modo ambient cuando un
ServiceEntryu otro servicio reclama la dirección de un waypoint con dirección IP. Crédito: Esta vulnerabilidad fue descubierta y reportada por yshch.
Otras correcciones de seguridad de Istio
Corregido que
istioctlomitiera la verificación del certificado de istiod al conectarse a XDS con un token de service account (istioctl proxy-status,istioctl x internal-debugy--xds-addressen general). Ahora istioctl verifica el servidor con el certificado raíz de Istio del configmapistio-ca-root-certy el nombre de servidor esperado:--authoritysi está definido, el host de--xds-addresssi es un nombre DNS, oistiod.<istio-namespace>.svcal conectarse a una dirección IP o a localhost. Usa--insecure(o defineISTIOCTL_INSECURE=true) para omitir la verificación de forma explícita. Crédito: Este problema fue reportado por Leon Zlobecki. (Issue #41937)Corregido que
istioctl manifest translateescribiera valores sin comillas de la entrada de IstioOperator (como el namespace y el nombre de la versión) en los scripts de shell de instalación generados. Valores manipulados podían inyectar comandos de shell adicionales al ejecutar esos scripts. Los argumentos ahora se escapan conshellescape.Quote. Crédito: Esta vulnerabilidad fue descubierta y reportada por OpenSec Intelligence.Corregido un panic en istiod cuando el autenticador OIDC/JWT recibía un token con un claim
submal formado. Ahora se valida que el sujeto tenga exactamente la formasystem:serviceaccount:<namespace>:<serviceaccount>antes de usarlo. Crédito: Este problema fue reportado por Kaizhe Huang.Corregido que
CreateCertificatedevolviera a los llamadores el texto sin procesar de los errores de la API de Kubernetes en la ruta experimental de RA de CSR de Kubernetes (EXTERNAL_CA=ISTIOD_RA_KUBERNETES_API), lo que filtraba nombres de CSR, nombres de firmantes y la identidad de istiod. Ahora el error completo solo se registra en el lado del servidor. Reportado por Juno Im.Corregido que el bucle de observación de CSR de Kubernetes usara un temporizador
time.Afterabandonado que podía dejar una goroutine en ejecución tras completarse la solicitud en la ruta experimental de RA de CSR de Kubernetes (EXTERNAL_CA=ISTIOD_RA_KUBERNETES_API). Ahora el bucle está acotado por uncontext.WithTimeoutcon el ámbito adecuado y se detiene de forma fiable ante un timeout o una cancelación. Reportado por Juno Im.Corregido que se aceptara un
ValidityDurationsolicitado por el cliente de hastaMAX_WORKLOAD_CERT_TTL(por defecto90d) en la ruta experimental de RA de CSR de Kubernetes (EXTERNAL_CA=ISTIOD_RA_KUBERNETES_API). Una nueva variable de entornoMAX_RA_WORKLOAD_CERT_TTL(por defecto48h) ahora limita el TTL, reduciendo el alcance del daño de un istio-token robado. Los despliegues que solicitaban legítimamente certificados con TTL >48hpor esta ruta deben aumentarMAX_RA_WORKLOAD_CERT_TTLtras la actualización. Reportado por Juno Im.Corregido que el recuperador de imágenes OCI de Wasm decidiera reintentar una descarga HTTPS fallida mediante HTTP en texto plano según el error devuelto por el registro. Dado que el registro es una entrada no confiable, un MITM o un registro malicioso podía activar este fallback a demanda para forzar el transporte en texto plano y, sin un digest de módulo opcional fijado, servir un binario Wasm arbitrario. Ahora el reintento en texto plano solo se intenta para los registros que el operador ha permitido explícitamente mediante
WASM_INSECURE_REGISTRIES. Crédito: Esta vulnerabilidad fue descubierta y reportada por Adam Korczynski.Corregido que los endpoints de depuración de istiod (
/debug/config_dump,/debug/edszy el tipo XDSistio.io/debug/config_dump) coincidieran conproxyIDcomo una subcadena, lo que permitía a un llamador leer la configuración de otros proxies de su propio namespace pasando un ID parcial. AhoraproxyIDdebe ser exactamente<pod>.<namespace>(o el ID de conexión completo); las formas cortas comoproxyID=istio-ingressgatewayya no coinciden. Crédito: Este problema fue reportado por 박현범.Mejorado: Añadido
PILOT_ENABLE_STRICT_GATEWAY_MERGINGpara evitar la fusión entre namespaces de los Gateways de Istio con los Gateways deGatewayAPIgestionados. Cuando está habilitado, los CRDs de Gateway de Istio de diferentes namespaces no se fusionarán con los proxies de Gateway deGatewayAPIgestionados. Los Gateways deGatewayAPIno gestionados (despliegue manual) no se ven afectados. Está deshabilitado por defecto en esta versión; definePILOT_ENABLE_STRICT_GATEWAY_MERGINGcomotruepara habilitarlo.
Cambios
Corregido que una regla de
HTTPRoutecon variosbackendRefsdeInferencePoolconfigurara un solo endpoint picker. El picker del últimobackendRefde la lista puntuaba todas las solicitudes de la regla, por lo que los pickers de los demás pools nunca se invocaban, y un pool sin endpoints listos hacía fallar toda la regla en lugar de solo su parte ponderada. Ahora cada pool tiene su propio picker, asociado a su propio clúster ponderado. (Issue #61594)Corregido que dos
HTTPRoutes que compartían unrules[].nameen el mismo gateway se sobrescribieran mutuamente el endpoint picker. Los nombres de regla solo tienen que ser únicos dentro de un mismoHTTPRoute, pero los pickers se indexaban por nombre entre todos ellos, de modo que una ruta podía ser atendida por el picker de otra. Ahora los pickers se resuelven porbackendRef, así que un nombre compartido ya no traslada el picker de una ruta a otra. (Issue #61594)Corregido que una regla de ruta perdiera su endpoint picker de
InferencePoolcuando también incluía un filtro CORS. Ambos se escriben en la misma configuración por filtro, y la ruta de CORS reemplazaba el mapa en lugar de añadirle elementos. (Issue #61594)Corregida la resolución de UID/GID del proxy sidecar en OpenShift para workloads vinculados a una
SecurityContextConstraintpersonalizada con un rango de UID estrecho o configurado explícitamente, que la anotación de rango de UID preasignado del namespace no anuncia. (Issue #61791)Añadida una advertencia de validación para direcciones de
ServiceEntryque sean catch-all (0.0.0.0,::), tengan una red no especificada (0.0.0.0/N,::/N) o sean un CIDR con un prefijo más corto que/8. UnServiceEntryasí conresolution: NONEy elexportTopor defecto puede hacer que todos los sidecars de la mesh dejen pasar el tráfico en sus puertos, eludiendooutboundTrafficPolicyREGISTRY_ONLY. Usa un CIDR más estrecho yexportTo: ["."]. Para aplicar el control de egress, usa un egress gateway con una NetworkPolicy. (Issue #62124)Corregido un problema por el cual el workload pre-serializado usado para la detección de cambios y el versionado en ambient no era estable cuando un workload tenía más de un servicio, lo que hacía que workloads sin cambios parecieran modificados en cada recálculo e impedía omitir los workloads sin cambios cuando un cliente se reconectaba.
Corregida una fuga de memoria y de goroutines en el modo multiclúster ambient de Istiod, donde las colecciones de localidad de nodo por clúster tenían el ámbito de la vida del proceso en lugar de la del clúster, por lo que nunca se liberaban al eliminar un clúster remoto. (Issue #60033)
Corregido un error por el cual se creaba incorrectamente un listener interno cuando el listener era HTTPS o TLS pero sin una sección TLS definida. Una versión posterior de la Gateway API impedirá que esta combinación de entradas llegue a un controlador. (Issue #60562)
Corregida una fuga de memoria en el modo multiclúster ambient, donde las colecciones se registraban en el depurador de krt pero nunca se eliminaban del registro cuando se quitaba un clúster remoto o cambiaba su configuración, causando que los registros del depurador se acumularan con el tiempo. (Issue #60033)
Corregido que los componentes de Istio se quedaran bloqueados indefinidamente cuando una solicitud a la API de Kubernetes no recibía respuesta, por ejemplo cuando un load balancer o proxy descarta silenciosamente la ruta de retorno. Antes, una solicitud así podía permanecer abierta para siempre, bloqueando el controlador que la emitió hasta que se reiniciara el proceso. Ahora las solicitudes expiran en el lado del cliente, de modo que una solicitud atascada se cancela y el componente se recupera por sí solo. Cada timeout se registra como advertencia y se contabiliza en la métrica
kube_client_deadline_fired_total. Los timeouts se pueden ajustar conISTIO_KUBE_HEADER_TIMEOUT(por defecto90s) eISTIO_KUBE_REQUEST_TIMEOUT(por defecto15m); define cualquiera de ellos como0para restaurar el comportamiento anterior sin límite.Corregido que ztunnel entrara en crash-loop con código de salida 133 (
SIGTRAP) en nodos arm64 cuyas CPUs proporcionan la instrucciónRNDR, como GKE Axion, cuando el generador de números aleatorios por hardware reportaba un fallo transitorio. Se actualizaaws-lc-rsa 1.18.2, que reintenta la lectura en lugar de abortar. (Issue #2072)