This release adds improvements related to the following components and concepts.
This release of {SMProductName} introduces new features, addresses Common Vulnerabilities and Exposures (CVEs), contains bug fixes, and is supported on {product-title} 4.9, 4.10, and 4.11.
| Component | Version |
|---|---|
Istio |
1.14 |
Envoy Proxy |
1.22.4 |
Jaeger |
1.38 |
Kiali |
1.57.3 |
The openshift-operators namespace includes a new istio CNI DaemonSet istio-cni-node-v2-3 and a new ConfigMap resource, istio-cni-config-v2-3.
When upgrading to Service Mesh Control Plane 2.3, the existing istio-cni-node DaemonSet is not changed, and a new istio-cni-node-v2-3 DaemonSet is created.
This name change does not affect previous releases or any istio-cni-node CNI DaemonSet associated with a Service Mesh Control Plane deployed using a previous release.
This release introduces generally available support for Gateway injection. Gateway configurations are applied to standalone Envoy proxies that are running at the edge of the mesh, rather than the sidecar Envoy proxies running alongside your service workloads. This enables the ability to customize gateway options. When using gateway injection, you must create the following resources in the namespace where you want to run your gateway proxy: Service, Deployment, Role, and RoleBinding.
{SMProductShortName} 2.3 is based on Istio 1.14, which brings in new features and product enhancements. While many Istio 1.14 features are supported, the following exceptions should be noted:
-
ProxyConfig API is supported with the exception of the image field.
-
Telemetry API is a Technology Preview feature.
-
SPIRE runtime is not a supported feature.
This release introduces a Developer Preview version of the {product-title} Service Mesh Console, which integrates the Kiali interface directly into the OpenShift web console. For additional information, see Introducing the OpenShift Service Mesh Console (A Developer Preview)
This release introduces cluster-wide deployment as a Technology Preview feature. A cluster-wide deployment contains a Service Mesh Control Plane that monitors resources for an entire cluster. The control plane uses a single query across all namespaces to monitor each Istio or Kubernetes resource kind that affects the mesh configuration. In contrast, the multitenant approach uses a query per namespace for each resource kind. Reducing the number of queries the control plane performs in a cluster-wide deployment improves performance.
The following example ServiceMeshControlPlane object configures a cluster-wide deployment.
To create an SMCP for cluster-wide deployment, a user must belong to the cluster-admin ClusterRole. If the SMCP is configured for cluster-wide deployment, it must be the only SMCP in the cluster. You cannot change the control plane mode from multitenant to cluster-wide (or from cluster-wide to multitenant). If a multitenant control plane already exists, delete it and create a new one.
This example configures the SMCP for cluster-wide deployment.
apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
name: cluster-wide
namespace: istio-system
spec:
version: v2.3
techPreview:
controlPlaneMode: ClusterScoped (1)-
Enables Istiod to monitor resources at the cluster level rather than monitor each individual namespace.
Additionally, the SMMR must also be configured for cluster-wide deployment. This example configures the SMMR for cluster-wide deployment.
apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
name: default
spec:
members:
- '*' (1)-
Adds all namespaces to the mesh, including any namespaces you subsequently create. The following namespaces are not part of the mesh: kube, openshift, kube-* and openshift-*.
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs), contains bug fixes, and is supported on OpenShift Container Platform 4.9 or later.
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs), bug fixes, and is supported on OpenShift Container Platform 4.9 or later.
| Component | Version |
|---|---|
Istio |
1.12.7 |
Envoy Proxy |
1.20.6 |
Jaeger |
1.36 |
Kiali |
1.48.2-1 |
With this enhancement, in addition to copying annotations, you can copy specific labels for an OpenShift route. {SMProductName} copies all labels and annotations present in the Istio Gateway resource (with the exception of annotations starting with kubectl.kubernetes.io) into the managed OpenShift Route resource.
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs), bug fixes, and is supported on OpenShift Container Platform 4.9 or later.
This release of {SMProductName} adds new features and enhancements, and is supported on OpenShift Container Platform 4.9 or later.
| Component | Version |
|---|---|
Istio |
1.12.7 |
Envoy Proxy |
1.20.4 |
Jaeger |
1.34.1 |
Kiali |
1.48.0.16 |
This release adds support for the WasmPlugin API and deprecates the ServiceMeshExtension API.
This release introduces service mesh support for Red Hat OpenShift on AWS (ROSA), including multi-cluster federation.
This release, the istio-node DaemonSet is renamed to istio-cni-node to match the name in upstream Istio.
Istio 1.10 updated Envoy to send traffic to the application container using eth0 rather than lo by default.
This release marks the end of support for {SMProductShortName} Control Planes based on Service Mesh 1.1 for all platforms.
{SMProductShortName} 2.2 is based on Istio 1.12, which brings in new features and product enhancements. While many Istio 1.12 features are supported, the following unsupported features should be noted:
-
AuthPolicy Dry Run is a tech preview feature.
-
gRPC Proxyless Service Mesh is a tech preview feature.
-
Telemetry API is a tech preview feature.
-
Discovery selectors is not a supported feature.
-
External control plane is not a supported feature.
-
Gateway injection is not a supported feature.
Kubernetes Gateway API is a technology preview feature that is disabled by default.
To enable the feature, set the following environment variables for the Istiod container in ServiceMeshControlPlane:
spec:
runtime:
components:
pilot:
container:
env:
PILOT_ENABLE_GATEWAY_API: true
PILOT_ENABLE_GATEWAY_API_STATUS: true
# and optionally, for the deployment controller
PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER: trueRestricting route attachment on Gateway API listeners is possible using the SameNamespace or All settings. Istio ignores usage of label selectors in listeners.allowedRoutes.namespaces and reverts to the default behavior (SameNamespace).
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs), contains bug fixes, and is supported on OpenShift Container Platform 4.9 or later.
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
With this release, the {JaegerName} Operator is now installed to the openshift-distributed-tracing namespace by default. Previously the default installation had been in the openshift-operator namespace.
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
This release also adds the ability to disable the automatic creation of network policies.
| Component | Version |
|---|---|
Istio |
1.9.9 |
Envoy Proxy |
1.17.1 |
Jaeger |
1.24.1 |
Kiali |
1.36.7 |
{SMProductName} automatically creates and manages a number of NetworkPolicies resources in the {SMProductShortName} control plane and application namespaces. This is to ensure that applications and the control plane can communicate with each other.
If you want to disable the automatic creation and management of NetworkPolicies resources, for example to enforce company security policies, you can do so. You can edit the ServiceMeshControlPlane to set the spec.security.manageNetworkPolicy setting to false
|
Note
|
When you disable |
-
In the {product-title} web console, click Operators → Installed Operators.
-
Select the project where you installed the {SMProductShortName} control plane, for example
istio-system, from the Project menu. -
Click the {SMProductName} Operator. In the Istio Service Mesh Control Plane column, click the name of your
ServiceMeshControlPlane, for examplebasic-install. -
On the Create ServiceMeshControlPlane Details page, click
YAMLto modify your configuration. -
Set the
ServiceMeshControlPlanefieldspec.security.manageNetworkPolicytofalse, as shown in this example.apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane spec: security: trust: manageNetworkPolicy: false
-
Click Save.
This release of {SMProductName} adds support for Istio 1.9.8, Envoy Proxy 1.17.1, Jaeger 1.24.1, and Kiali 1.36.5 on {product-title} 4.6 EUS, 4.7, 4.8, 4.9, along with new features and enhancements.
| Component | Version |
|---|---|
Istio |
1.9.6 |
Envoy Proxy |
1.17.1 |
Jaeger |
1.24.1 |
Kiali |
1.36.5 |
New Custom Resource Definitions (CRDs) have been added to support federating service meshes. Service meshes may be federated both within the same cluster or across different OpenShift clusters. These new resources include:
-
ServiceMeshPeer- Defines a federation with a separate service mesh, including gateway configuration, root trust certificate configuration, and status fields. In a pair of federated meshes, each mesh will define its own separateServiceMeshPeerresource. -
ExportedServiceMeshSet- Defines which services for a givenServiceMeshPeerare available for the peer mesh to import. -
ImportedServiceSet- Defines which services for a givenServiceMeshPeerare imported from the peer mesh. These services must also be made available by the peer’sExportedServiceMeshSetresource.
Service Mesh Federation is not supported between clusters on Red Hat OpenShift Service on AWS (ROSA), Azure Red Hat OpenShift (ARO), or OpenShift Dedicated (OSD).
The OVN-Kubernetes Container Network Interface (CNI) was previously introduced as a Technology Preview feature in {SMProductName} 2.0.1 and is now generally available in {SMProductName} 2.1 and 2.0.x for use on {product-title} 4.7.32, {product-title} 4.8.12, and {product-title} 4.9.
The ServiceMeshExtensions Custom Resource Definition (CRD), first introduced in 2.0 as Technology Preview, is now generally available. You can use CRD to build your own plug-ins, but Red Hat does not provide support for the plugins you create.
Mixer has been completely removed in Service Mesh 2.1. Upgrading from a Service Mesh 2.0.x release to 2.1 will be blocked if Mixer is enabled. Mixer plug-ins will need to be ported to WebAssembly Extensions.
With Mixer now officially removed, OpenShift Service Mesh 2.1 does not support the 3scale mixer adapter. Before upgrading to Service Mesh 2.1, remove the Mixer-based 3scale adapter and any additional Mixer plugins. Then, manually install and configure the new 3scale WebAssembly adapter with Service Mesh 2.1+ using a ServiceMeshExtension resource.
3scale 2.11 introduces an updated Service Mesh integration based on WebAssembly.
{SMProductShortName} 2.1 is based on Istio 1.9, which brings in a large number of new features and product enhancements. While the majority of Istio 1.9 features are supported, the following exceptions should be noted:
-
Virtual Machine integration is not yet supported
-
Kubernetes Gateway API is not yet supported
-
Remote fetch and load of WebAssembly HTTP filters are not yet supported
-
Custom CA Integration using the Kubernetes CSR API is not yet supported
-
Request Classification for monitoring traffic is a tech preview feature
-
Integration with external authorization systems via Authorization policy’s CUSTOM action is a tech preview feature
The amount of time {SMProductName} uses to prune old resources at the end of every ServiceMeshControlPlane reconciliation has been reduced. This results in faster ServiceMeshControlPlane deployments, and allows changes applied to existing SMCPs to take effect more quickly.
Kiali 1.36 includes the following features and enhancements:
-
{SMProductShortName} troubleshooting functionality
-
Control plane and gateway monitoring
-
Proxy sync statuses
-
Envoy configuration views
-
Unified view showing Envoy proxy and application logs interleaved
-
-
Namespace and cluster boxing to support federated service mesh views
-
New validations, wizards, and distributed tracing enhancements
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs), bug fixes, and is supported on OpenShift Container Platform 4.9 or later.
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs), bug fixes, and is supported on OpenShift Container Platform 4.9 or later.
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs).
{SMProductName} contains a remotely exploitable vulnerability, CVE-2021-39156, where an HTTP request with a fragment (a section in the end of a URI that begins with a # character) in the URI path could bypass the Istio URI path-based authorization policies. For instance, an Istio authorization policy denies requests sent to the URI path /user/profile. In the vulnerable versions, a request with URI path /user/profile#section1 bypasses the deny policy and routes to the backend (with the normalized URI path /user/profile%23section1), possibly leading to a security incident.
You are impacted by this vulnerability if you use authorization policies with DENY actions and operation.paths, or ALLOW actions and operation.notPaths.
With the mitigation, the fragment part of the request’s URI is removed before the authorization and routing. This prevents a request with a fragment in its URI from bypassing authorization policies which are based on the URI without the fragment part.
To opt-out from the new behavior in the mitigation, the fragment section in the URI will be kept. You can configure your ServiceMeshControlPlane to keep URI fragments.
|
Warning
|
Disabling the new behavior will normalize your paths as described above and is considered unsafe. Ensure that you have accommodated for this in any security policies before opting to keep URI fragments. |
ServiceMeshControlPlane modificationapiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
metadata:
name: basic
spec:
techPreview:
meshConfig:
defaultConfig:
proxyMetadata: HTTP_STRIP_FRAGMENT_FROM_PATH_UNSAFE_IF_DISABLED: "false"Istio generates hostnames for both the hostname itself and all matching ports. For instance, a virtual service or Gateway for a host of "httpbin.foo" generates a config matching "httpbin.foo and httpbin.foo:*". However, exact match authorization policies only match the exact string given for the hosts or notHosts fields.
Your cluster is impacted if you have AuthorizationPolicy resources using exact string comparison for the rule to determine hosts or notHosts.
You must update your authorization policy rules to use prefix match instead of exact match. For example, replacing hosts: ["httpbin.com"] with hosts: ["httpbin.com:*"] in the first AuthorizationPolicy example.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
action: DENY
rules:
- from:
- source:
namespaces: ["dev"]
to:
- operation:
hosts: [“httpbin.com”,"httpbin.com:*"]apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: default
spec:
action: DENY
rules:
- to:
- operation:
hosts: ["httpbin.example.com:*"]This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
{SMProductName} is now supported through {product-dedicated} and Microsoft Azure Red Hat OpenShift.
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
|
Important
|
There are manual steps that must be completed to address CVE-2021-29492 and CVE-2021-31920. |
Istio contains a remotely exploitable vulnerability where an HTTP request path with multiple slashes or escaped slash characters (%2F or %5C) could potentially bypass an Istio authorization policy when path-based authorization rules are used.
For example, assume an Istio cluster administrator defines an authorization DENY policy to reject the request at path /admin. A request sent to the URL path //admin will NOT be rejected by the authorization policy.
According to RFC 3986, the path //admin with multiple slashes should technically be treated as a different path from the /admin. However, some backend services choose to normalize the URL paths by merging multiple slashes into a single slash. This can result in a bypass of the authorization policy (//admin does not match /admin), and a user can access the resource at path /admin in the backend; this would represent a security incident.
Your cluster is impacted by this vulnerability if you have authorization policies using ALLOW action + notPaths field or DENY action + paths field patterns. These patterns are vulnerable to unexpected policy bypasses.
Your cluster is NOT impacted by this vulnerability if:
-
You don’t have authorization policies.
-
Your authorization policies don’t define
pathsornotPathsfields. -
Your authorization policies use
ALLOW action + pathsfield orDENY action + notPathsfield patterns. These patterns could only cause unexpected rejection instead of policy bypasses. The upgrade is optional for these cases.
|
Note
|
The {SMProductName} configuration location for path normalization is different from the Istio configuration. |
Istio authorization policies can be based on the URL paths in the HTTP request. Path normalization, also known as URI normalization, modifies and standardizes the incoming requests' paths so that the normalized paths can be processed in a standard way. Syntactically different paths may be equivalent after path normalization.
Istio supports the following normalization schemes on the request paths before evaluating against the authorization policies and routing the requests:
| Option | Description | Example | Notes |
|---|---|---|---|
|
No normalization is done. Anything received by Envoy will be forwarded exactly as-is to any backend service. |
|
This setting is vulnerable to CVE-2021-31920. |
|
This is currently the option used in the default installation of Istio. This applies the |
|
This setting is vulnerable to CVE-2021-31920. |
|
Slashes are merged after the BASE normalization. |
|
Update to this setting to mitigate CVE-2021-31920. |
|
The strictest setting when you allow all traffic by default. This setting is recommended, with the caveat that you must thoroughly test your authorization policies routes. Percent-encoded slash and backslash characters ( |
|
Update to this setting to mitigate CVE-2021-31920. This setting is more secure, but also has the potential to break applications. Test your applications before deploying to production. |
The normalization algorithms are conducted in the following order:
-
Percent-decode
%2F,%2f,%5Cand%5c. -
The RFC 3986 and other normalization implemented by the
normalize_pathoption in Envoy. -
Merge slashes.
|
Warning
|
While these normalization options represent recommendations from HTTP standards and common industry practices, applications may interpret a URL in any way it chooses to. When using denial policies, ensure that you understand how your application behaves. |
Ensuring Envoy normalizes request paths to match your backend services' expectations is critical to the security of your system.
The following examples can be used as a reference for you to configure your system.
The normalized URL paths, or the original URL paths if NONE is selected, will be:
-
Used to check against the authorization policies.
-
Forwarded to the backend application.
| If your application… | Choose… |
|---|---|
Relies on the proxy to do normalization |
|
Normalizes request paths based on RFC 3986 and does not merge slashes. |
|
Normalizes request paths based on RFC 3986 and merges slashes, but does not decode percent-encoded slashes. |
|
Normalizes request paths based on RFC 3986, decodes percent-encoded slashes, and merges slashes. |
|
Processes request paths in a way that is incompatible with RFC 3986. |
|
To configure path normalization for {SMProductName}, specify the following in your ServiceMeshControlPlane. Use the configuration examples to help determine the settings for your system.
spec:
techPreview:
global:
pathNormalization: <option>In some environments, it may be useful to have paths in authorization policies compared in a case insensitive manner.
For example, treating https://myurl/get and https://myurl/GeT as equivalent.
In those cases, you can use the EnvoyFilter shown below.
This filter will change both the path used for comparison and the path presented to the application. In this example, istio-system is the name of the {SMProductShortName} control plane project.
Save the EnvoyFilter to a file and run the following command:
$ oc create -f <myEnvoyFilterFile>apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: ingress-case-insensitive
namespace: istio-system
spec:
configPatches:
- applyTo: HTTP_FILTER
match:
context: GATEWAY
listener:
filterChain:
filter:
name: "envoy.filters.network.http_connection_manager"
subFilter:
name: "envoy.filters.http.router"
patch:
operation: INSERT_BEFORE
value:
name: envoy.lua
typed_config:
"@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
inlineCode: |
function envoy_on_request(request_handle)
local path = request_handle:headers():get(":path")
request_handle:headers():replace(":path", string.lower(path))
endThis release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
In addition, this release has the following new features:
-
Added an option to the
must-gatherdata collection tool that gathers information from a specified {SMProductShortName} control plane namespace. For more information, see OSSM-351. -
Improved performance for {SMProductShortName} control planes with hundreds of namespaces
This release of {SMProductName} adds support for IBM Z and IBM Power Systems. It also addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
This release of {SMProductName} addresses Common Vulnerabilities and Exposures (CVEs) and bug fixes.
This release of {SMProductName} adds support for Istio 1.6.5, Jaeger 1.20.0, Kiali 1.24.2, and the 3scale Istio Adapter 2.0 and {product-title} 4.6.
In addition, this release has the following new features:
-
Simplifies installation, upgrades, and management of the {SMProductShortName} control plane.
-
Reduces the {SMProductShortName} control plane’s resource usage and startup time.
-
Improves performance by reducing inter-control plane communication over networking.
-
Adds support for Envoy’s Secret Discovery Service (SDS). SDS is a more secure and efficient mechanism for delivering secrets to Envoy side car proxies.
-
-
Removes the need to use Kubernetes Secrets, which have well known security risks.
-
Improves performance during certificate rotation, as proxies no longer require a restart to recognize new certificates.
-
Adds support for Istio’s Telemetry v2 architecture, which is built using WebAssembly extensions. This new architecture brings significant performance improvements.
-
Updates the ServiceMeshControlPlane resource to v2 with a streamlined configuration to make it easier to manage the {SMProductShortName} Control Plane.
-
Introduces WebAssembly extensions as a Technology Preview feature.
-