Release notes

Review summaries of the main changes in the 2.13 release.

Introduction

The release notes include important installation changes and known issues. They also highlight ways that you can take advantage of new features or enhancements to improve your product usage.

For more information, see the following related resources:

• Upgrade guide: Steps to upgrade from the previous minor version to the current version.
• Version reference: Information about Solo’s version support.
• Changelog: A full list of changes, including the ability to compare previous patch and minor versions.

🔥 Breaking changes

Review details about the following breaking changes. To review when breaking changes were released, you can use the comparison feature of the changelog. The severity is intended as a guide to help you assess how much attention to pay to this area during the upgrade, but can vary depending on your environment.

🚨 High

Review severe changes that can impact production and require manual intervention.

• No high-severity changes are currently reported.

🔔 Medium

Review changes that might have impact to production and require manual intervention, but possibly not until the next version is released.

• No medium-severity changes are currently reported.

ℹ️ Low

Review informational updates that you might want to implement but that are unlikely to materially impact production.

Auto-generated extauth signing key

In version 2.13.1 and later, the extauth service is upgraded from version 0.74.1 to 0.80.1 to address HIGH and CRITICAL CVEs. The new version of extauth requires a valid signing key at all times and no longer accepts an empty signing key (""). When you upgrade to version 2.13.1, if no signing key is configured (no SIGNING_KEY environment variable is set on the Gloo UI), Gloo Mesh (Gloo Platform APIs) automatically creates a Kubernetes Secret that contains a randomly generated signing key. If you run multiple UI replicas, all replicas use this shared secret. If you already set a SIGNING_KEY environment variable, no action is required.

🚧 New known issues

No new known issues are currently reported.

🌟 New features

Review the following new features that are introduced in version 2.13 and that you can enable in your environment.

Istio 1.30 support

You can now run Gloo Mesh (Gloo Platform APIs) with Istio 1.30. Istio 1.25 is no longer supported. For more information, see the version support matrix, and the Solo distribution of Istio changelog for 1.30.

meshctl get insights command

Use the new meshctl get insights command to retrieve insights from the Gloo Mesh insights system. You can filter results by category, cluster, insight code, and severity, and choose from table, JSON, or CSV output formats.

Redis diff stream compression

In large cluster environments where the management server’s Redis diff stream payloads grow large enough to destabilize Redis, you can now enable the RedisDiffStreamCompression feature gate to compress and decompress diffs that are written to the Redis diff stream. This setting reduces payload size and can prevent Redis crashes. The feature must be enabled on both the management server and the Gloo UI, and is not compatible with rolling upgrades. For more information, see Redis diff stream compression.

JWKS fetch retry and backoff for JWTPolicy

Two new optional fields are available on JWTPolicy.spec.config.providers.<name>.remote to control how Envoy handles failed JWKS fetch attempts:

• retryPolicy: Use numRetries to set the number of per-cycle retry attempts, and backoff.baseInterval and backoff.maxInterval to configure exponential backoff between retries.
• failedRefetchDuration: Sets how long Envoy waits after all retries in a cycle are exhausted before starting the next fetch cycle. This field only takes effect when enableAsyncFetch: true. If you set failedRefetchDuration with enableAsyncFetch: false, the JWTPolicy reports a WARNING status and the field has no effect.

Both fields are optional. Existing JWTPolicy resources that do not set these fields translate to the same Envoy configuration as before. For more information, see the JWTPolicy API reference.

🗑️ Removed features

Removed support for Istio 1.25

Istio 1.25 is no longer supported with Gloo Mesh (Gloo Platform APIs) version 2.13. For more information, see the version support matrix.

XListenerSet removed from the UI and insights

Gateway API 1.5 replaced the experimental XListenerSet resource with the stable ListenerSet resource. The Gloo UI and insights no longer support XListenerSet. To continue using listener sets, use EnterpriseListenerSet or the standard Kubernetes Gateway API ListenerSet resource.

🚧 Known issues

The Solo team fixes bugs, delivers new features, and makes changes on a regular basis as described in the changelog. Some issues, however, might impact many users for common use cases. These known issues are as follows:

• Cluster names: Do not use underscores (_) in the names of your clusters or in the kubeconfig context for your clusters.
• Istio:
  • The JWT policy translator serializes workload-key identifiers using a "." delimiter. If a gateway pod carries labels with dots in the key name (for example, app.kubernetes.io/name), the serialization produces an ambiguous key that breaks label-selector matching. Affected JWT authentication policies fail open, meaning requests that should be rejected based on JWT claims are allowed through without authentication. As a workaround, use dot-free label keys on gateway pods that are targeted by JWT authentication policies. For example, replace app.kubernetes.io/name: my-gateway with app: my-gateway as the selector label. This issue is resolved in Gloo Mesh Enterprise 2.14.
  • If you use Istio versions 1.27.7, 1.28.4, 1.29.0 or later, and you install the Gloo Mesh (Gloo Platform APIs) management plane (Gloo UI) into a namespace other than gloo-mesh, you must allow that namespace by listing it in the DEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACES environment variable of your istiod installation. For more information, see the release notes.
  • Patch versions 1.26.0 and 1.26.1 of the Solo distribution of Istio lack support for FIPS-tagged images. When upgrading or installing 1.26, be sure to use patch version 1.26.1-patch0 and later only.
  • In the Solo distribution of Istio 1.25 and later, you can access enterprise-level features by passing your Solo license in the license.value or license.secretRef field of the Solo distribution of the istiod Helm chart. The Solo istiod Helm chart is strongly recommended due to the included safeguards, default settings, and upgrade handling to ensure a reliable and secure Istio deployment. Though it is not recommended, you can pass your license key in the open source istiod Helm chart by using the --set pilot.env.SOLO_LICENSE_KEY field.
  • Istio patch versions 1.25.1 and 1.24.4 contain an upstream certificate rotation bug in which requests with more than one trusted root certificate cannot be validated. If you use Gloo Mesh (Gloo Platform APIs) to manage root certificate rotation and use Istio 1.25 or 1.24, be sure to use 1.25.2 or 1.24.5 and later only.
  • Due to a lack of support for the Istio CNI and iptables for the Istio proxy, you cannot run Istio (and therefore Gloo Mesh (Gloo Platform APIs)) on AWS Fargate. For more information, see the Amazon EKS issue.
• OTel pipeline: FIPS-compliant builds are not currently supported for the OTel collector agent image.
• Route name and matcher changes: When performing a bulk update for the name or matchers of a route in a RouteTable resource, the translation of the Istio VirtualService and EnvoyFilter might take some time to complete leading to policies temporarily not being applied to your routes. For more information about this issue and mitigation strategies, see Bulk route name and matcher updates.