Introducing Red Hat OpenShift Service Mesh 3.4

Red Hat OpenShift Service Mesh 3.4 is generally available with Red Hat OpenShift and Red Hat OpenShift Platform Plus. Based on the Istio, Envoy, and Kiali projects, this release updates the version of Istio to 1.30, and Kiali to 2.27. Several updates to Istio’s sidecar-less ambient mode and more are included. Kiali introduces a new overview page to better manage service meshes at scale, while bringing AI-powered capabilities with Red Hat OpenShift Lightspeed to technology preview to help you diagnose and resolve issues faster. This post will also provide a preview of what is to come later this year.

Note that OpenShift Service Mesh 2.6 reached its end of life on June 30, 2026. If you are still running 2.6 without an approved support extension, see notes at the end of this post on how to proceed.

Kiali’s new multi-cluster aware overview page

OpenShift Service Mesh at Red Hat Summit

Red Hat Summit 2026 took place in May in Atlanta, Georgia. In case you missed it, OpenShift Service Mesh featured heavily in the Red Hat OpenShift product spotlight. This included 2 customers discussing their experience with service mesh as well as a demo that included service mesh with OpenShift Virtualization and a forward-looking demo using service mesh with agentic AI troubleshooting.

Based on Istio 1.30 and Kiali 2.27

This release jumps 2 minor Istio releases from OpenShift Service Mesh 3.3, incorporating changes from Istio 1.29 and 1.30. These 2 releases include significant updates to Istio’s ambient mode, particularly for multicluster. Kiali jumps to version 2.27, which includes major updates to the overview and detail pages. We'll highlight some of the more notable changes here, but the complete list of updates can be seen in the Istio 1.29 and 1.30 change notes and the Kiali release notes. For product support specifics, please see the OpenShift Service Mesh 3.4 feature support tables.

Ambient mode updates

This release features several updates to Istio’s sidecar-less ambient mode, which continues to mature toward feature parity with Istio’s traditional sidecar mode.

Coexistence and migration guidance from sidecar mode

This release introduces official support and guidance for the coexistence of ambient mode and sidecar mode workloads within the same service mesh, as well as supported guidance on migrating workloads from sidecar mode to ambient mode. Both procedures note several limitations that currently exist for coexistence and migration of workloads between ambient and sidecar mode. The migration is intended to be gradual and reversible, with ambient and sidecar workloads coexisting for an ongoing period.

Multicluster in ambient mode continues to mature (technology preview)

This release includes many updates to Istio ambient mode’s multi-primary multinetwork (multicluster) feature set, including updated documentation in OpenShift Service Mesh for installing a multi-primary multinetwork mesh in ambient mode.

As a reminder, Istio’s multi-cluster topologies extend the scope of a single mesh across multiple clusters, providing a single point for observing traffic and managing policies across multiple clusters, availability zones, and regions. They're particularly useful for creating highly available applications, with Istio’s locality based load balancing allowing traffic to be routed based on physical or geographic location. For sidecar mode, this is a generally available feature in OpenShift Service Mesh.

This release includes significant enhancements and bug fixes that bring ambient mode multicluster closer to production readiness. This includes fixing a bug where ingress gateways did not route requests to exposed remote backends. This fix is behind the feature flag AMBIENT_ENABLE_MULTI_NETWORK_INGRESS, which is false by default.

Improvements have been made to the telemetry implementation, closing gaps related to the exchange of peer metadata and telemetry across network boundaries where waypoints are used. These features may require the feature flag AMBIENT_ENABLE_BAGGAGE to be enabled. The Istio project now also provides an in-depth guide for configuring multinetwork ambient mode with Kiali.

Support for multi-primary multinetwork (multicluster) with Istio’s ambient mode is a technology preview feature in OpenShift Service Mesh 3.4. While we don't yet recommend it for production use, we encourage OpenShift Service Mesh users to begin development and experimentation with this feature and to report feedback.

Certificate Revocation List (CRL) support in ztunnel

This release adds Certificate Revocation List (CRL) support to ztunnel, enabling ambient mode to validate and reject revoked certificates when using external certificate authorities. Similar to sidecar mode, this can be configured using a ca-crl.pem file supplied alongside your plugged-in CA files in ClientTLSSettings. The Istio control plane (Istiod) will automatically distribute these CRLs to all participating namespaces in the cluster.

Native nftables support for RHEL 10 and beyond

This release provides native nftables support for both sidecar and ambient mode. This feature was contributed by Red Hat to prepare Istio for future versions of Red Hat Enterprise Linux (RHEL) and OpenShift. Nftables provide an alternative means of managing network rules to traditional iptables, which will be required when using service mesh with RHEL 10 and beyond.

Network policies for core Istio components

To improve the security of the Istio’s core components (istiod, istio-cni and ztunnel), Red Hat introduced an optional set of network policies that lock down these components to the minimum set of ingress ports that each component needs. These policies can be enabled by setting global.networkPolicy.enabled=true in your Istio resource’s values configuration. 

In OpenShift Service Mesh 3.4, these will be off by default, but they will be turned on by default in a future minor release of OpenShift Service Mesh.

Kubernetes Gateway API enhancements

Kubernetes Gateway API support within Istio continues to evolve. This release of service mesh includes significant updates with support for Kubernetes Gateway API 1.5. Note that Gateway API support on Openshift requires the installation of Custom Resource Definitions (CRDs), and currently the supported version of these CRDs that are available will depend on the OpenShift platform version.

This release adds full support for TLSRoute termination and mixed mode as well as TLS passthrough for east-west gateways, a key feature for supporting encrypted cross-cluster traffic in Istio’s ambient mode. 

The Gateway resource now includes the option to specify custom cipher suites using the gateway.istio.io/tls-cipher-suites annotation. Status reporting of the Gateway resource has been improved to include the number of attached ListenerSets, while ListenerSet status reporting now includes the number of Routes attached.

Finally, if you're only using Kubernetes Gateway API to configure your service mesh (GAMMA), or you're using Istio only as an Ingress controller (for north-south traffic only), you may not want the full breadth of resources and features that Istio includes out of the box. The new PILOT_IGNORE_RESOURCES environment variable can be used to optimize Istio by ignoring resources that aren't needed for your use cases. This can reduce the footprint of Istio, saving memory and configuration reconciliation time.

Zero trust workload identity manager support (technology preview)

This release updates OpenShift Service Mesh’s support with Red Hat’s zero trust workload identity manager (based on SPIRE) to technology preview. While OpenShift Service Mesh includes out-of-the-box workload identity and creation using the SPIFFE protocol, zero trust workload identity manager, available with Red Hat OpenShift Platform Plus, provides stronger, multifactor workload identity attestation backed by hardware or cloud environment verification. This gives extra reassurance that a workload legitimately matches its claimed identity.

Zero trust workload identity manager also includes a powerful feature called federation that enables workloads that are part of different trust domains to authenticate and communicate with each other in a protected fashion. Combining this with service mesh simplifies and enhances security for the sharing of trust, regardless of whether those workloads are in different service meshes, clusters, or standalone environments such as virtual machines (VMs).

This integration was detailed in a series of blog posts, including extending the use case to an external virtual machine.

New TrafficExtension API (technology preview)

This release also introduces a new API for extending Istio, the TrafficExtension API. While Istio is very feature rich, we find many customers have specialized use cases that require Istio’s functionality to be extended by using either the EnvoyFilter API (a low-level API that carries significant risk of breakage across updates) or WebAssembly plugins (good for complex use cases, but can be cumbersome to build and distribute). 

The TrafficExtension API aims to provide a single unified and improved API for extending Istio’s functionality. It incorporates the functionality from the WasmPlugin API (which it aims to replace), but also adds support for Lua scripts embedded directly into the resource with no module distribution required. This provides a lighter-weight method of extending Istio that also aims to be safer than an EnvoyFilter. Like other Istio resources, TrafficExtensions can be configured and managed using Kiali. For more information, see extending Envoy proxies.

New Kiali overview and detail pages with improved multicluster support

The Kiali console and its sister OpenShift Service Mesh Console plugin provide a centralized location for observing, managing, and protecting both Istio and the services that make up your service mesh.

This release includes a completely redesigned overview page in Kiali (shown in the screenshot above). This has been done to improve readability and performance for large multicluster service mesh deployments that may have several hundred namespaces. The new architecture reduces memory usage and render time, while the updated layout is multicluster aware, emphasizing global health status with application insights at a glance. Similar updates have been made to the OpenShift Service Mesh Console plugin overview page.

An updated namespaces page provides better support for large multicluster meshes with advanced filtering, sorting, and the mTLS status for each namespace. 

Kiali’s updated multi-cluster aware namespace page

Examining a particular namespace provides an updated summary and graph view of that namespace. Drilling down into a particular workload provides a similar summary view with a graph displaying the dependencies for that workload.

Kiali’s updated namespace details page

Kiali’s updated workload details page

AI-powered service mesh assistance (technology preview)

The complexity of Istio  and the wealth of information that Kiali has access to (including metrics, logs, and traces) makes it an ideal place for AI to provide assistance. In the Kiali console, this can be used by setting up Kiali’s own chatbot. This release adds token usage analytics to help you monitor and control costs. The system prompt has also been hardened against injection attacks to prevent malicious input from leaking sensitive mesh configuration or credentials.

For even more power and integration, use Model Connect Protocol (MCP) in combination with OpenShift Lightspeed to assist with service mesh and the rest of the OpenShift platform. The OpenShift Model Connect Protocol (MCP) server recently made technology preview and includes tools specifically for Kiali and OpenShift Service Mesh. 

These can be used in combination with the Kiali console or the OpenShift Service Mesh console plugin to monitor your mesh while you interact with it via the Lightspeed or your agentic environment of choice using MCP.

OpenShift Lightspeed with the OpenShift Service Mesh Console plugin

We've already seen that this combination helps lower the barriers for both common service mesh use cases, such as traffic splitting (shown above and demoed here), telemetry analysis, identifying configuration errors to complex troubleshooting scenarios (demo here), and other tasks that may have previously required deep Istio expertise (or a lot of time hunting around documentation).

Improved namespace multitenancy in Kiali

Kiali has added a new configuration option, KialiFeatureFlags.Authz.RequireNamespaceGet, allowing administrators to restrict namespace visibility to only those namespaces where users have explicit "get" permissions (not just "list"). This is useful in single-mesh multitenant environments where users should see only their own namespaces, not the full cluster inventory.

What’s coming next

While this release featured a range of updates to both Istio and Kiali, we have several more big features to look forward to later this year. We're working toward bringing ambient mode’s multi-primary multinetwork (multicluster) topology to general availability. We plan to extend our VM support to include workloads on separate networks, including workloads that aren't part of an OpenShift cluster. Support for integrating RHEL VMs is a developer preview feature. We're also looking at extensions to Red Hat Advanced Cluster Management for Kubernetes to improve the configuration and management of service mesh across a fleet of clusters.

End of the life for OpenShift Service Mesh 2.6

OpenShift Service Mesh 2.6 reached its end of life on June 30, 2026. While we'll continue to support customers in migrating to a supported version of OpenShift Service Mesh 3, we are no longer providing bug fixes and security fixes for OpenShift Service Mesh 2.6.

If you're still running OpenShift Service Mesh 2.6, please reach out to your Red Hat account representative to discuss a support extension and a migration timeline. Detailed information about the differences between OpenShift Service Mesh 2.6 and 3.0 are described here, with an in-depth migration guide that details a zero-downtime procedure covering a variety of different production setups. We're happy to discuss individual situations or challenges.

Getting started or upgrading to OpenShift Service Mesh 3.4

If you're new to service mesh, the installation guide walks through installing Istio with the OpenShift Service Mesh 3 operator. The operator handles installation and upgrades of Istio including multiple service meshes on a single cluster (sidecar mode only) or multiple clusters within a service mesh.

For those upgrading from OpenShift Service Mesh 3.3, review the release notes for a list of important changes to be aware of before upgrading. Follow the updating documentation for OpenShift Service Mesh for the detailed upgrade procedure.

Learn more about Red Hat OpenShift Service Mesh.