📋 Recommended Actions
⚠️ Action Required
Immediate review is required due to security enhancements for Gateway API TLS secret access. Operations engineers should update to ensure gateways continue to function correctly, especially if relying on previous implicit permissions. Also, review the newENABLE_PROXY_FIND_POD_BY_IPflag for potential future impacts.
📝 Summary
Istio 1.26.5 delivers crucial security and stability enhancements. This release significantly hardens Kubernetes Gateway API TLS secret access, now requiring both namespace and service account matching for referenced secrets—a vital update for secure operations. You’ll also find improved installation flexibility as the Istio CNI no longer depends directly on Pilot, streamlining deployments. For ambient mode users, ServiceEntry named port mapping logic is now correctly aligned with sidecar behavior, resolving previous inconsistencies. Additionally, a new feature flag, ENABLE_PROXY_FIND_POD_BY_IP, grants more control over pod-proxy association, with future versions defaulting it to ‘off’. Critical bug fixes address issues like XDS cache corruption during SDS config dumps and Gateway API meshconfig reconciliation, ensuring a more robust and predictable service mesh. Review these updates promptly to maintain a secure and efficient Istio environment.
🔒 Hardened Gateway API TLS Secret Access
To bolster the security posture of your Istio deployments, this release introduces a significant enhancement to how Kubernetes Gateway API gateways access referenced TLS secrets. Previously, access was primarily restricted by namespace. Now, for managed gateways, the system mandates both a matching namespace AND service account for secret retrieval, or an explicit ReferenceGrant must be in place. This prevents unintended access to sensitive credentials, ensuring that only authorized gateway workloads can retrieve the necessary TLS secrets.
The gateway_collection.go logic now populates an internal.istio.io/service-account-name annotation on internally generated Istio Gateway configurations. The pilot/pkg/model/gateway.go then leverages this annotation to verify the requesting proxy’s identity against the expected service account name when a TLS credential is referenced. If the service account does not match, the credential access is denied, preventing the server from being configured with the secret. Gateways using a hostname address continue to be restricted by namespace only.
Source:
pilot/pkg/config/kube/gateway/gateway_collection.go(100-112, 112-124)pilot/pkg/model/gateway.go(190-195)pkg/config/constants/constants.go(126-133)releasenotes/notes/verify-sa-for-gateway-secrets.yaml(1-24)
🚀 Decoupled Istio CNI and Pilot Installation
This release brings greater flexibility to your Istio installation process by removing the direct dependency between the Istio CNI and Pilot components. Previously, installing Pilot often required the CNI to be ready first, which could complicate certain deployment scenarios. Now, the CNI can be installed independently, no longer blocking Pilot’s readiness and allowing for more concurrent or staggered deployments in complex environments. This change primarily benefits those who manage CNI configuration separately or utilize an Istio-owned CNI config.
The dependency list in operator/pkg/install/install.go has been updated. Specifically, CNIComponentName is no longer a prerequisite for PilotComponentName. Instead, BaseComponentName now has CNIComponentName as a dependency. This ensures that the core Istio components are properly initialized without forcing a strict CNI-first order for Pilot.
Source:
⚙️ Consistent Gateway API Reconciliation for MeshConfig Changes
Maintaining consistent configuration across your Gateway API deployments is crucial. This update ensures that any changes to your global MeshConfig, such as modifications to the default proxy image, automatically trigger a reconciliation process for all Gateway API resources. This means your gateways will always reflect the latest mesh-wide settings, eliminating potential inconsistencies and reducing the need for manual intervention to propagate configuration updates.
The DeploymentController in pilot/pkg/config/kube/gateway now registers a handler with the environment’s Watcher.AddMeshHandler. When a MeshConfig change is detected, this handler iterates through all existing Gateway API objects and queues them for re-processing. This ensures that the Gateway controller re-evaluates and updates the associated deployments (e.g., ingress gateways) to match the new MeshConfig.
Source:
pilot/pkg/config/kube/gateway/deploymentcontroller.go(289-299, 323-328)releasenotes/notes/57890.yaml(1-10)
🛠️ Ambient Mode: ServiceEntry Port Mapping Fix
For users operating in ambient mode, this release addresses a critical bug concerning ServiceEntry port resolution within ztunnel. Previously, ServiceEntries without an explicit targetPort field might not have correctly mapped to pod container ports, leading to unexpected traffic routing issues. This fix ensures that ServiceEntry port names are now accurately matched to pod container port names, bringing ambient mode behavior in line with sidecar semantics and improving overall traffic management reliability.
The constructServices function in pilot/pkg/serviceregistry/kube/controller/ambient/workloads.go has been updated. It now includes specific logic for ServiceEntry kind, where if no explicit targetPort is defined, it attempts to match by ServiceEntry port name to Pod container port name. If that fails and targetPort is 0, it falls back to the ServicePort. This ensures correct port mapping for ServiceEntries in ambient environments.
Source:
pilot/pkg/serviceregistry/kube/controller/ambient/workloads.go(754-777)releasenotes/notes/57713.yaml(1-10)
🔮 New Feature Flag: ENABLE_PROXY_FIND_POD_BY_IP
We’re introducing a new feature flag, ENABLE_PROXY_FIND_POD_BY_IP, to provide finer-grained control over how Istio’s pod controller associates proxies with their corresponding pods. By default, this flag is set to true, maintaining the existing behavior where if a pod cannot be found by its name and namespace, an IP-based lookup is attempted. However, you now have the option to disable this IP-based search, which will become the default in future releases. This gives operators more control and visibility over the pod discovery mechanism.
The pilot/pkg/features/pilot.go file introduces ENABLE_PROXY_FIND_POD_BY_IP, an environment variable that defaults to true. In pilot/pkg/serviceregistry/kube/controller/pod.go, the getPodByProxy function now conditionally executes the IP-based pod lookup (pc.getPodsByIP(proxyIP)) only if this feature flag is enabled. This allows operators to explicitly opt-out of IP-based pod discovery if it causes issues or isn’t desired in their environment.
Source:
pilot/pkg/features/pilot.go(269-272)pilot/pkg/serviceregistry/kube/controller/pod.go(348-372)releasenotes/notes/pod-controller-avoid-ip-search.yaml(1-8)
Minor Updates & Housekeeping
This release also includes dependency bumps for istio.io/api and istio.io/client-go to v1.26.5, along with updates to build-tools images. Several minor fixes enhance stability, such as correctly prioritizing reroute-virtual-interfaces over kubevirtInterfaces in the CNI and preventing XDS cache corruption when dumping SDS secrets.