SupportConsoleDevelopersStart a trialContact

Chapter 1. OpenShift Service Mesh release notes

Review new features, compatibility updates, fixed issues, and known issues for Red Hat OpenShift Service Mesh to stay informed about changes across different product versions.

1.1. Red Hat OpenShift Service Mesh version 3.4.3
Copy link

This release of Red Hat OpenShift Service Mesh is included with the Red Hat OpenShift Service Mesh Operator 3.4.3. To view the OpenShift Container Platform versions that support OpenShift Service Mesh 3.4.3, see OpenShift Operator Life Cycles. Service Mesh 3.4.3 includes the following fixed issue.

1.1.1. Fixed issue
Copy link

Proxies enforce correct cipher suites from OpenShift TLS security profiles

Before this update, Service Mesh proxies did not correctly enforce OpenShift TLS security profiles. When configured with the modern profile, TLS version 1.3, and tlsAdherence set to StrictAllComponents, proxies accepted cipher suites outside the profile. This issue no longer occurs. Proxies correctly enforce only the cipher suites specified in the OpenShift TLS security profile.

OSSM-15376

For supported versions of Service Mesh 3.4.3 components (such as the control plane and IstioCNI), see "Service Mesh component versions".

1.2. Red Hat OpenShift Service Mesh version 3.4.2
Copy link

This release of Red Hat OpenShift Service Mesh is included with the Red Hat OpenShift Service Mesh Operator 3.4.2. To view the OpenShift Container Platform versions that support OpenShift Service Mesh 3.4.2, see OpenShift Operator Life Cycles. Service Mesh 3.4.2 addresses Common Vulnerabilities and Exposures (CVEs) and includes the following fixed issues.

1.2.1. Fixed issues
Copy link

OpenSSL memory allocations visible in tcmalloc heap diagnostics

Before this update, OpenSSL memory allocations operated on a separate heap from the intended Envoy tcmalloc allocator, bypassing performance optimizations on the TLS hot path and keeping allocations invisible to tcmalloc heap dumps and memory profilers. With this release, OpenSSL uses the tcmalloc allocator. As a result, OpenSSL benefits from tcmalloc optimizations, and its memory usage is fully visible in heap diagnostics for accurate troubleshooting.

OSSM-15244

Namespace administrators can manage Istio resources without cluster-admin privileges

Before this update, Istio CRD aggregation ClusterRoles were not created when istiod was installed through the pkg/install library (which is the path used by the Cluster Ingress Operator) rather than the Red Hat Operator Lifecycle Manager (OLM). As a consequence, the admin, edit, and view roles could not access istio.io resources such as Telemetry, VirtualService, and AuthorizationPolicy. Users with these roles received forbidden errors, which forced them to obtain cluster-admin privileges to manage the resources.

With this release, the pkg/install library creates the aggregation ClusterRoles correctly. As a result, users no longer need cluster-admin access to work with Istio resources.

OSSM-15257

Service mesh sidecar proxies no longer leak memory when closing TLS connections

Before this update, a reference count leak in the SSL_get0_peer_certificates() OpenSSL compatibility implementation prevented peer X.509 certificate objects from being released when connections closed. This issue occurred when client certificate forwarding (forward_client_cert_details) was set to any mode other than SANITIZE. As a result, certificate objects accumulated, causing memory usage in service mesh sidecar proxies to grow over time, proportional to the volume of closed TLS connections. Because APPEND_FORWARD is the default setting for inbound listeners in mutual TLS (mTLS) environments, nearly all mTLS-enabled sidecar proxies were affected.

This release corrects the reference counting issue for peer certificate objects in SSL_get0_peer_certificates(). Certificate objects are properly released when connections close.

OSSM-15075

For supported component versions in Service Mesh 3.4.2 (components such as the control plane and IstioCNI), see "Service Mesh component versions".

1.3. Red Hat OpenShift Service Mesh version 3.4.1
Copy link

This release of Red Hat OpenShift Service Mesh is included with the Red Hat OpenShift Service Mesh Operator 3.4.1. To view the OpenShift Container Platform versions that support OpenShift Service Mesh 3.4.1, see OpenShift Operator Life Cycles. Service Mesh 3.4.1 addresses Common Vulnerabilities and Exposures (CVEs) and includes the following fixed issue.

1.3.1. Fixed issues
Copy link

Webhook error "failed calling webhook validation.istio.io" no longer occurs

After the Service Mesh 3.3.4 upgrade, the istiod-default-validator webhook did not point to the control plane if the Istio CR used a non-default name with the IstioRevisionTag set to default. As a consequence, attempts to update Istio networking, security, or telemetry resources failed with the error failed calling webhook "validation.istio.io". Existing mesh traffic continued to function, but you were unable to change the service mesh configuration. With this release, the validating webhook references the correct control plane service. As a result, Istio resource validation succeeds in deployments that use non-default Istio CR names.

OSSM-14646

For supported component versions in Service Mesh 3.4.1, see "Service Mesh component versions".

This release makes Red Hat OpenShift Service Mesh 3.4 generally available, adds new features, addresses Common Vulnerabilities and Exposures (CVEs), and is supported on OpenShift Container Platform 4.20 and later versions.

For lists of supported component versions and feature support levels, see:

  • Service Mesh component versions

  • Service Mesh feature support tables

    Service Mesh compatibility with Red Hat Enterprise Linux 10

    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

    OpenShift Service Mesh supports FIPS 140-3 compliance

    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

    OpenShift Service Mesh supports the coexistence of sidecar and ambient mode workloads

    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

    Kiali reduces false warnings in multi-cluster AuthorizationPolicies

    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:

  • New validation message KIA0108 - Unable to verify principal, trust domain is not known to Kiali appears when a trust domain is genuinely unknown.

  • Existing validation KIA0107 - Service Account for this principal found on a remote cluster was downgraded from Warning to Informational, eliminating false warnings for working multi-cluster configurations.

    OSSM-13864

    Kiali supports stricter namespace access control for multi-tenancy environments

    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

    Kiali Overview page redesigned for performance and multi-cluster awareness

    This release replaces the Kiali Overview page with a compact, multi-cluster-aware dashboard that provides a high-level view of mesh health at a glance. The redesigned page uses pre-computed and cached data to ensure fast rendering independent of mesh size.

    The Overview page displays summary cards for:

  • Cluster health
  • Istio configuration validation
  • Control plane status
  • Namespace mesh participation (Ambient, Sidecar, or Out of mesh)
  • An interactive application health donut chart

  • Workload insights such as missing sidecars, high error rates, or failing probes

    This release also adds a dedicated Namespaces page.

    OSSM-11833

    Kiali Namespace detail page provides a comprehensive namespace view

    Clicking a namespace in the Kiali Namespaces list opens a detail page with a split-panel layout showing namespace metadata, health, and traffic.

    The left panel displays:

  • Namespace attributes such as cluster, revision, status, mesh mode, and mTLS status
  • Links to applications, services, workloads, and Istio configuration with health breakdowns

  • Editable labels and annotations with click-to-filter navigation

    The right panel displays a namespace-scoped traffic minigraph.

    Additionally, an Actions menu lists options such as traffic policies. The page also supports breadcrumb navigation, view-only mode, and kiosk mode.

    OSSM-13271

    OpenShift Service Mesh supports Gateway API 1.5.1, in which the following features are now stable
  • ListenerSet for simplified gateway listener configuration
  • TLSRoute for routing encrypted non-HTTP traffic
  • HTTPRoute CORS configuration for cross-origin API access
  • Client certificate validation for mutual TLS authentication at the gateway
  • Certificate selection for multi-domain gateway TLS configurations

  • ReferenceGrant for cross-namespace access delegation

    Additionally, for teams serving AI/ML models with Red Hat OpenShift, this release supports Gateway API Inference Extension 1.4.0. This extension provides intelligent routing and load balancing optimized for GPU-accelerated inference workloads.

    OSSM-11956

    Performance and security improvements from upstream Istio and the Sail Operator
    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:
  • Circuit breaker metrics tracking is disabled by default to improve proxy memory usage. Before this update, this tracking was enabled by default. To reenable it, set the environment variable DISABLE_TRACK_REMAINING_CB_METRICS=false in istiod. This affects the track_remaining setting in Envoy’s circuit breaker configuration.
  • Debug endpoint authorization is now enabled by default. This change affects tools that access debug endpoints from non-system namespaces. For example, this change might affect Kiali if you deploy it in a different namespace from the Istio control plane. This release restricts non-system namespaces to specific debug endpoints only, with access limited to config_dump, ndsz, and edsz for same-namespace proxies. To restore the previous behavior, set the environment variable ENABLE_DEBUG_ENDPOINT_AUTH=false in istiod.
  • HTTP compression for Envoy metrics is now enabled by default. The sidecar.istio.io/statsCompression annotation was removed. This release replaces it with a new statsCompression option in proxyConfig that defaults to true. Envoy now compresses metrics using brotli, gzip, or zstd based on the Accept-Encoding header. You can override per-pod compression, if needed, by using the proxy.istio.io/config annotation.
  • DNS proxying is now enabled by default for workloads in an ambient mesh. This ensures that Istio correctly resolves and tracks ServiceEntry destinations. DNS traffic from already-running workloads is not automatically redirected through ztunnel when you enable or upgrade ambient mode. To enable DNS proxying for these existing pods, manually restart them. Alternatively, configure Istio CNI with --set cni.ambient.reconcileIptablesOnStartup=true to reconcile the required iptables rules automatically. This setting is enabled by default in Istio 1.29 and later versions. (Note that DNS capture is still not enabled by default in sidecar mode, as ServiceEntry resources are correctly handled at the sidecar proxy with default settings.)

This release includes some features that are currently in Technology Preview. These experimental features are not intended for production use.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

SPIRE integration enables zero-trust workload identity

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:

  • Deep workload attestation - Verifies workload identity based on configurable criteria backed by hardware or cloud environment verification

  • Trust domain federation - Enables workloads from different trust domains to authenticate and communicate securely

    SPIRE is supported as part of the OpenShift Zero Trust Workload Identity Manager. Integration with OpenShift Service Mesh is a Technology Preview feature.

    For more information, see SPIRE integration for mesh security.

    OSSM-9387

Multi-cluster support in Istio ambient mode

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

Multi-network ingress gateway support in ambient mode

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:

  • AMBIENT_ENABLE_MULTI_NETWORK_INGRESS - Allows ingress gateways to route traffic to remote clusters. This enables load balancing across local and remote pods and ensures requests are served even when local pods are unavailable.

  • AMBIENT_ENABLE_BAGGAGE - Ensures service mesh telemetry metrics include accurate source and destination labels for cross-network traffic.

    Both variables support ambient mode in multi-primary multi-network topologies and are therefore Technology Preview features.

    OSSM-13455

This release addresses the following fixed issues:

Istiod containers include termination message policy for easier debugging

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

Kiali correctly validates Istio configuration for multiple meshes in a cluster

Before this update, when multiple Istio control planes ran in the same OpenShift cluster, Kiali used only one control plane’s MeshConfig properties to validate all Istio configurations. As a consequence, Kiali reported incorrect KIA1101 (VirtualService) and KIA0203 (DestinationRule) validation errors. This release validates Istio resources within the context of each control plane’s managed namespace, using each control plane’s own MeshConfig properties. As a result, resources belonging to one mesh are validated independently, and false validation errors no longer appear.

OSSM-12562

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top