Introducing OpenShift Service Mesh 3.3 with post-quantum cryptography

Red Hat OpenShift Service Mesh 3.3 is now generally available with Red Hat OpenShift Container Platform and Red Hat OpenShift Platform Plus. Based on the Istio, Envoy, and Kiali projects, this release updates the version of Istio to 1.28 and Kiali to 2.22, and is supported on OpenShift Container Platform 4.18 and above. While this release includes many updates, it also sets the stage for the next generation of service mesh features, including post-quantum cryptographic (PQC) encryption, AI enablement, and support for the inclusion of external virtual machines (VMs) with service mesh.

Updates in Istio 1.28

Istio 1.28 includes several major updates, including notable security feature enhancements and traffic management enhancements with support for Gateway API v1.4 and BackendTLSPolicy v1. 

Notable Red Hat contributions in Istio 1.28 include: 

• An improved JWT filter configuration to support custom space-delimited claims
• Default Kubernetes NetworkPolicies for Istio to make it easier for administrators to secure their service mesh
• Nftable support for ambient mode, which enables support for service mesh with Red Hat Enterprise Linux 10 (support coming with Red Hat OpenShift 5)

There have also been significant developments to ambient mode’s multicluster deployments, which enable us to upgrade this feature to Technology Preview. For a full list of updates in Istio 1.28, please see the announcement and detailed change notes.

Introducing post-quantum encryption support

This release introduces support for PQC algorithms in service mesh. These new algorithms help to confirm that the encryption used with Istio’s gateways and workload proxies works against a new generation of threats that will arise as quantum computing becomes more widely available.

Why is quantum computing a security concern?

Quantum computing represents an exciting up-and-coming technology, offering the ability to run complex calculations in a tiny fraction of the time they would take on a classical computer. But these same powers can be applied to break the encryption algorithms that are widely used in sensitive information and workloads today. This includes the standard algorithms used for Istio’s mTLS encryption. These threats—and the algorithms that mitigate them—were described in detail in our preview announcement of configuring Istio gateways with PQC algorithms.

A new generation of PQC algorithms and standards have been developed to mitigate these concerns. The most notable of these is the hybrid X25519MLKEM768 key exchange, which helps protect against both classical and quantum attacks while maintaining compatibility with existing systems.

While quantum computing may seem like a distant concern, one major current threat is what’s known as a “harvest now, decrypt later” (HDNL) attack, in which bad actors steal encrypted data with the intent of using quantum computers to decode that data in the future. This is why it’s important to start preparing critical systems today for a post-quantum future.

How does service mesh help to address these concerns?

With the need to modify and update encryption algorithms across the board, standardized approaches to applying encryption—such as the approaches typically provided with a service mesh—significantly reduce the effort to update workloads at scale to post quantum cryptography algorithms and beyond. 

OpenShift Service Mesh 3.3 adds support for quantum secure encryption with the X25519MLKEM768 algorithm. This feature must be configured explicitly for both gateways and in-mesh traffic using the Istio resource. 

Note that these algorithms cannot yet be used on OpenShift clusters running in FIPS mode, as this mode enforces the use of RHEL cryptographic libraries that have been submitted to NIST for FIPS 140-2/140-3 validation. The X25519MLKEM768 algorithm has yet to be submitted. 

Evolving sidecar-less ambient mode

In OpenShift Service Mesh 3.2, we introduced support for Istio’s ambient mode, a sidecar-less dataplane that significantly reduces the resource costs of running a service mesh. 

As this represents a revolutionary change to the Istio dataplane, we anticipate that it will continue to evolve over the coming months and years. There are still features that are supported with Istio’s sidecar mode that are not yet supported with ambient mode. Kubernetes Gateway API is primarily used to configure L7 traffic with ambient mode, and Gateway API itself is still a relatively new and evolving standard. It has outstanding feature gaps relative to Istio APIs, the most notable at this time being VirtualService, which is still considered Alpha as of Istio 1.28. All this is to say that you can expect a steady stream of updates to ambient mode going forward.

Support in FIPS mode

In this release, we are adding support for Istio’s ambient mode to be used on OpenShift clusters running in FIPS mode. For now, FIPS 140-2 support has been made available by adding support for TLS 1.2 to Istio’s ztunnel, which has been backported to OpenShift Service Mesh 3.3 and will be shortly backported to 3.2. Support for FIPS 140-3 with TLS 1.3 will follow in an upcoming release.

Improved upgrades documentation

As discussed in our blog post that introduced OpenShift Service Mesh 3.2, upgrading an ambient mode mesh requires special considerations due to the shared ztunnel and waypoint proxies. In sidecar mode, the sidecar proxy lifecycles are coupled with their application workloads; in contrast, the shared proxies of ambient mode are managed independently. This has some benefits—application workloads do not need to be restarted during service mesh upgrades. It also comes with some risk—restarting the shared ztunnel has the potential to momentarily disrupt application traffic if not done with care. To help users navigate upgrades, we have added additional detailed documentation on the procedures for upgrading ambient mode in OpenShift Service Mesh.

Multicluster with ambient mode is now Technology Preview

Since we released OpenShift Service Mesh 3.0, we have observed that multicluster service mesh deployments have become commonplace amongst our users. The most popular deployment model has been the multiprimary multinetwork topology, which provides the redundancy of multiple control planes and enables high availability between applications without having to create a common network setup between clusters. In particular, the use of gateways between clusters means that overlapping IP or VIP ranges are allowed.

Multicluster with ambient mode continues to develop in the community with a focus on the multiprimary multinetwork mode, which we are now declaring Technology Preview. This means that we have validated the configuration and will be adding content about it to the Red Hat OpenShift Service Mesh product documentation, but we do not yet recommend it for production environments. Several limitations remain, so this feature is currently best for advanced users who are already experienced at deploying OpenShift Service Mesh in ambient mode on a single cluster and want to experiment with a multicluster setup. 

Kiali updates

Performance and scale enhancements with large meshes

Over the years, Kiali has introduced many improvements aimed at making it easier to navigate very large meshes. For example, it is recommended to use the Manual refresh mode when working with large meshes to first configure the options and filters desired for the graph before the initial render.

This release introduces additional caching to improve the responsiveness of Kiali in larger, complex meshes. Backend caching of the traffic graph improves the re-rendering time after the first rendering. Users can navigate away and then back to the traffic graph, and resume with the latest cached graph within the timeout period (10 minutes by default). The health status is now also cached to improve the responsiveness of the Overview and List pages, with a default duration of 5 minutes. Users may notice that the Duration dropdown selector has been removed from the Overview and List pages.

Updated look and a new notification center

Kiali will have an updated look and feel in OpenShift Service Mesh 3.3 with the update to Patternfly 6. This includes a new, more polished notification center. 

Stay tuned for even more updates to Kiali’s overview page in a coming Kiali and OpenShift Service Mesh release that will make it easier to manage large multicluster mesh deployments.

OpenShift Service Mesh Console and Network Observability

The OpenShift Service Mesh Console plugin integrates service mesh observability and management into the OpenShift Console, adding a new Service Mesh menu to the main page, as well as new tabs for metrics, logs, and traces in the Workload and Service pages.

For a lower-level view of network traffic (Layer 3-4), the network observability operator for Red Hat OpenShift can be used to view traffic metrics, including for workloads that are not part of a service mesh. This can now be accessed via the Service Mesh traffic graph for deployments when network observability is available.

Coming soon: Upcoming Developer Preview features

While the following features are not yet ready for production use, we are excited to give a preview of some of the up and coming features for OpenShift Service Mesh. 

Kiali’s AI chatbot and MCP integrations

While a service mesh provides incredible power to observe, control, and enhance the security of your application network, it also comes with a lot of complexity and terminology, and that can make for a very steep learning curve. As Kiali has access to both the Istio control plane and a wide range of standardized observability metrics, it has always been an indispensable console for understanding your service mesh and the workloads involved. Making the most of Kiali still requires a moderate level of technical knowledge of both Istio and the workloads.

This is where we think using natural language with AI will be incredibly powerful for lowering the barrier to entry, helping users get the most out of service mesh—whether it’s their first day trying to understand Istio or their fifth year managing a large-scale mesh with complex multicluster workflows.

To enable this, Kiali is introducing a native AI-powered chatbot that can be used with your model of choice. This is still in early development, and will evolve over the coming year, but can be seen on one of the many demo videos on the Kiali Youtube channel.

In addition to the native chatbot, Kiali has also integrated a variety of tools into the Kubernetes MCP server. This allows Kiali to be used via AI agents or your tool of choice, including with Red Hat OpenShift Lightspeed. Check out a demo of OpenShift Lightspeed being used with Kiali to troubleshoot workloads that are part of a service mesh.

Note that these features are all Developer Preview, and will continue to evolve over the coming year along with the OpenShift MCP server.

OpenShift Service Mesh with external VM workloads

While the use of a service mesh is usually associated with containerized workloads, most users also have workloads that have not yet been—or never will be—containerized. These workloads may be managed by OpenShift Container Platform using Red Hat OpenShift Virtualization or they may be running completely independent of any Red Hat OpenShift cluster. In the case of OpenShift Virtualization, there has long been support for using OpenShift Service Mesh for workloads communicating on the pod network. It is also quite common for VM workloads to communicate using a secondary network. In the case of a workload that is completely independent of OpenShift Container Platform, it will almost certainly be on a secondary network with other VMs rather than the pod network.

To address these use cases, Istio has a virtual machine architecture that can be used to include workloads that are completely external to Kubernetes—even on separate networks. Until recently, we have listed this as an unsupported feature of OpenShift Service Mesh. With the realignment with community Istio provided by OpenShift Service Mesh 3 and further testing, we are now declaring this feature to be Developer Preview. This will enable Red Hat OpenShift users to extend the benefits of a service mesh—standardized observability, security, and control—to VM or bare metal workloads. 

A recent Red Hat Developer learning path demonstrated how to include a VM with OpenShift Service Mesh. Look for an upcoming Red Hat developer blog post for even more information. In a future release of OpenShift Service Mesh, we will provide the option for customers to obtain support for adding external workloads with service mesh.

Zero trust workload identity manager

Red Hat recently made zero trust workload identity manager generally available with OpenShift Platform Plus. This offering uses SPIFFE/SPIRE to provide a framework for more consistent workload identity management across a wide range of workloads and environments. 

A service mesh includes out-of-the-box support for workload identity creation and management—also using the SPIFFE protocol, in the case of Istio. SPIRE, however, extends this functionality with ability to perform deep workload attestation based on a configurable set of criteria. This gives extra reassurance that a workload legitimately matches its claimed identity.

SPIRE also includes a powerful feature called federation that enables workloads that are part of different trust domains, potentially in very different distributed environments, to authenticate and communicate with each other securely. Combined with service mesh, this can enable workloads that are part of different meshes, different clusters or even standalone workloads (such as external VMs as described above) to be able to authenticate and communicate with each other securely.

Istio already includes an integration with SPIRE, which we are testing and validating with OpenShift Service Mesh. Expect to see a Red Hat developer blog post on zero trust workload identity manager with OpenShift Service Mesh in the near future.

Getting started with OpenShift Service Mesh 3.3

To get started with OpenShift Service Mesh 3.3, follow the documentation. To upgrade from OpenShift Service Mesh 3.2, follow the upgrade documentation. Note that if you are on an older version of OpenShift Service Mesh, you will need to update in sequence to version 3.2 before performing the upgrade to 3.3. If you are still on version 2.6 or older of service mesh, see the OpenShift Service Mesh 3.0 migration documentation.