Skip to content

For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

Release notes

Page as Markdown
Review summaries of the main changes in the 2.14 release.
Caution
Make sure that you review the breaking changes đŸ”Ĩ that were introduced in this release and the impact that they have on your current environment.
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.
ext-auth-service strips claimsToHeaders and headersFromMetadata headers when source value is absent

Previously, when an OAuth2 claimsToHeaders mapping or an API-key headersFromMetadata mapping had no value to inject (because the claim was absent or the metadata entry was missing), ext-auth-service left the header untouched on the request. A client-supplied value for that header could pass through to the upstream, creating an identity injection risk. Starting in version 2.14, ext-auth-service strips the header when the source value is absent, preventing client-supplied values from bypassing headers that ext-auth-service owns.
Additionally, an append-mode claimsToHeaders mapping permanently switched to overwrite mode after its first use, which could overwrite a client-supplied header value or strip the header when the claim was subsequently absent. The mapping now consistently uses append mode across all requests.
If your deployment relies on a client-supplied header value passing through when the corresponding OAuth claim or metadata entry is absent, set PRESERVE_UNSET_INJECTED_HEADERS=true on the ext-auth-service Deployment to restore the previous behavior. Set the variable via extAuthService.extraEnvs in your Helm values:
extAuthService:
  extraEnvs:
    PRESERVE_UNSET_INJECTED_HEADERS:
      value: "true"
This setting re-enables the fail-open behavior that the fix addresses. Use it only as a temporary measure while updating upstreams that depend on the previous behavior.
ℹī¸ Low

Review informational updates that you might want to implement but that are unlikely to materially impact production.
  • No low-severity changes are currently reported.
🚧 New known issues

No new known issues are currently reported.
🌟 New features

Review the following new features that are introduced in version 2.14 and that you can enable in your environment.
AllowedClientHeadersOnSuccess for HTTP passthrough auth

The HTTP passthrough auth configuration now supports an AllowedClientHeadersOnSuccess field. On a successful (200) passthrough auth response, headers in this list that are present on the auth server’s response are forwarded to the downstream client. Headers absent from the auth response are not added, and headers not in the list are never forwarded. When the field is unset, behavior is unchanged.
Istio 1.31 support

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

Review the following changes that might impact how you use certain features in your environment.
🐛 Bug fixes

ext-auth-service no longer drops response headers in multi-config chains

In AuthConfig chains with multiple auth services, response_headers_to_add and headers_to_remove from an earlier successful auth service were discarded when a later successful service returned its own OkHttpResponse. These fields are now merged across the chain (concatenated, earlier service first). Additionally, when a user ID header was configured, rebuilding the OkHttpResponse to append the header dropped other fields, such as OIDC Set-Cookie headers and credential-header stripping. Both cases are fixed.
JWT policy translator fixed for gateways with dotted label selectors

In Gloo Mesh Enterprise versions before 2.14, the JWT policy translator serialized workload-key identifiers using a "." delimiter. A gateway Service selector containing label keys with dots (for example, mesh.example.com/channel) produced an ambiguous workload key that failed to parse, causing all JWTPolicy resources targeting that gateway to go to FAILED status and fail open. The workload key serialization now handles dotted label keys correctly.
🗑ī¸ Removed features

Removed support for Istio 1.26

Istio 1.26 is no longer supported with Gloo Mesh (Gloo Platform APIs) version 2.14. For more information, see the version support matrix.
🚧 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:
    • 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_ISTIO_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.
Gloo Mesh (Gloo Platform APIs) changelog