Chapter 1. OpenShift Service Mesh release notes

Red Hat OpenShift Service Mesh 3.4 introduces native nftables support for traffic management in both sidecar and ambient modes. This support is required for clusters running on Red Hat Enterprise Linux (RHEL) 10 or Red Hat Enterprise Linux CoreOS (RHCOS) 10, where the legacy iptables framework has been removed.

OpenShift Service Mesh relies on packet filtering rules to redirect network traffic to the proxy. Because RHEL 10 systems use nftables exclusively, you must enable native nftables support to ensure that the service mesh can initialize and manage network traffic correctly on these hosts.

To enable native nftables support, set the values.global.nativeNftables parameter to true when you install or update the Service Mesh control plane.

If you use ambient mode, you might need to reboot nodes after enabling nftables. For guidance, see Nftables migration in ambient mode.

OSSM-6748

On FIPS-enabled OpenShift Container Platform clusters, Service Mesh supports FIPS 140-3 for both sidecar and ambient modes, ensuring continued compliance after the FIPS 140-2 standard expires on September 21, 2026. This release adds TLS 1.3 support for all mesh traffic in addition to the existing TLS 1.2 support, providing stronger encryption for mesh communications. The minimum TLS version remains TLS 1.2.

OSSM-12531

Service Mesh supports running sidecar proxy and ambient mode workloads simultaneously in separate namespaces within the same mesh (with limitations noted in the documentation). This coexistence enables an incremental migration to ambient mode. You can also maintain specific workloads in sidecar mode if they require features that ambient mode does not yet support.

For more information, see Coexistence of ambient and sidecar modes.

OSSM-11487

In this release, Kiali validates trust domains in AuthorizationPolicies by checking the trustDomainAliases field in the Istio MeshConfig. This enhanced validation provides more accurate feedback when working with federated multi-cluster meshes.

This enhancement introduces two validation message changes:

This release introduces a new configuration attribute, KialiFeatureFlags.Authz.RequireNamespaceGet, to improve multi-tenancy support in Kiali. By default, when Kiali runs in cluster-wide mode, it treats users with List permission to a namespace as also having Get permission, and displays all List namespaces in the Namespace dropdown. In environments where List and Get permissions differ, this can expose namespaces that users should not access. When you set KialiFeatureFlags.Authz.RequireNamespaceGet=true, Kiali limits the Namespace dropdown to only those namespaces for which users have Get permission, ensuring stricter access control. The default value is false, so existing deployments are not affected.

OSSM-13288

As a distribution based on upstream Istio and the Sail Operator, OpenShift Service Mesh inherits enhancements from these projects. Review the following upstream changes in this release to determine whether your deployment needs configuration updates:

Red Hat OpenShift Service Mesh integrates with the SPIFFE Runtime Environment (SPIRE) to provide stronger cryptographically verifiable workload identities. SPIFFE (Secure Production Identity Framework for Everyone) is an open standard for establishing trust between workloads in distributed systems.

While OpenShift Service Mesh already supports workload identity creation and management through the SPIFFE protocol, SPIRE extends this with:

Support for ambient mode in multi-primary multi-network topologies continues to be a Technology Preview feature.

For more information, see Installing a multi-primary multi-network mesh in ambient mode.

OSSM-12578

This release adds cross-cluster networking for ingress gateways in multi-network ambient deployments. You can configure two environment variables in the Istio resource under spec.values.pilot.env:

Before this update, istiod containers did not specify a terminationMessagePolicy. As a consequence, when an istiod container failed, you had to retrieve log information from log storage systems for troubleshooting. This release sets the terminationMessagePolicy to FallbackToLogsOnError. As a result, when a container fails, the last chunk of log output is captured in the pod status and accessible with oc describe pod, making initial debugging easier without requiring log storage access.

OSSM-13701