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:

đŸ”Ĩ Breaking changes

Review details about the following breaking changes. To review when breaking changes were released, you can use the comparison feature of the open source changelog or enterprise 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.

Envoy version 1.31 upgrade

The Envoy dependency in Gloo Gateway 1.18 was upgraded from 1.29.x to 1.31.x. This upgrade includes the following changes. For more information about these changes, see the Envoy changelog documentation.

  • Opencensus: Opencensus was marked as deprecated in previous Envoy releases. Starting in the 1.31.x Envoy release, Opencensus is now disabled by default. If Opencensus is set, Envoy rejects the configuration. If you still need time to transition off Opencensus, you can use Envoy’s layered_runtime section to enable deprecated configuration so that you can continue using Opencensus. However, note that Opencensus is completely removed in Envoy version 1.32.x.
  • JWT tokens: The behavior for extracting JWT tokens changed in the 1.29.x Envoy release. Previously, the JWT token was cut into non-base64 characters. Now, the entire JWT token is passed for validation. You can no longer revert this change by setting envoy.reloadable_features.token_passed_entirely to false as this option was removed in the 1.31.x Envoy release.
  • JWT_authn: Provider URIs that are defined in the jwt_authn section are now validated for RFC-compliance. Envoy might fail to start correctly if non-compliant URIs are found. If the URI validation is too strict, you can temporarily disable it by setting the runtime guard envoy.reloadable_features.jwt_authn_validate_uri to false. Common URI issues that were previously ignored, include:
    • Hostname contains an underscore character (_)
    • URL contains non-English characters (ASCII code > 127)
    • URL contains an unencoded character such as a space ( )
    • URL contains TAB (ASCII code 9) or FormFeed (ASCII code 12) characters
  • JWT_authn: The provider forward configuration changed. Previously, JWTs could only be removed from headers. Starting in Envoy version 1.31.x, JWTs can now be removed from query parameters. You can temporarily revert this change by setting envoy.reloadable_features.jwt_authn_remove_jwt_from_query_params to false.
  • access_log: The following access log format specifiers changed:
    • The upstream connection address is now used for the %UPSTREAM_REMOTE_ADDRESS%, %UPSTREAM_REMOTE_PORT% and %UPSTREAM_REMOTE_ADDRESS_WITHOUT_PORT% access log format specifiers. Previously, the upstream host address was used. You can temporarily revert this change by setting the runtime guard envoy.reloadable_features.upstream_remote_address_use_connection to false.
    • The %UPSTREAM_CLUSTER_RAW% access log formatter was added to log the original upstream cluster name, regardless of whether alt_stat_name is set.
    • SNIs are automatically sanitized for potential log injection. The invalid characters are replaced by underscores _ with an invalid: marker. To disable this feature, set envoy.reloadable_features.sanitize_sni_in_access_log is set to false.
  • YAML parsing: The behavior for parsing YAML configuration changed. Previously, malformed boolean values and fraction objects that set true or false as a string value were still interpreted as boolean values. Now, true or false string values are no longer interpreted as boolean values. You can revert this change by setting envoy.reloadable_features.reject_invalid_yaml to false.
  • HTTP/2: HTTP/2 colon prefixed headers are now sanitized by Envoy. Previously, sanitation was performed by the nghttp2 library, which caused pseudo headers with upper case letters to fail validation. Now, these pseudo headers pass validation. You can temporarily revert this change by setting the runtime guard envoy.reloadable_features.sanitize_http2_headers_without_nghttp2 to false.
  • Local ratelimit: The token bucket implementation changed. Previously, a timer-based token bucket was used to assign tokens to connections. In Envoy 1.31.x, the new AtomicToken bucket is used that is no longer timer-based. Tokens are now automatically refilled when the token bucket is accessed. Because of this change, the x-ratelimit-reset header is no longer sent. You can temporarily revert this change by setting the runtime guard envoy.reloadable_features.no_timer_based_rate_limit_token_bucket to false.

🔔 Medium

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

Kubernetes Gateway API version 1.1 and 1.2

Gloo Gateway is fully conformant with the Kubernetes Gateway API version 1.1 and 1.2. When upgrading from version 1.17.x to 1.18.x, make sure to first upgrade the Kubernetes Gateway APIs. Then, continue with the Gloo Gateway upgrade.

Review the changes that were introduced to Gloo Gateway:

  • TCPRoute support: You can now use TCPRoute resources to set up a TCP listener on your Gateway. Note that in order to use TCPRoutes, you must use the experimental channel of the Kubernetes Gateway API.

      kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/experimental-install.yaml

    If you do not want to use TCPRoutes, you can install the CRDs from the standard channel.

      kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml

  • EndpointSlices API support: Gloo Gateway now supports the EndpointSlices API when creating Upstream endpoints. The EndpointSlice API reached general availability (GA) in Kubernetes version 1.21. kube-proxy on both Linux and Windows uses EndpointSlices by default. To read more about EndpointSlices and how they affect scalability, see this blog.

ℹī¸ 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.

⚒ī¸ Installation changes

In addition to comparing differences across versions in the changelog, review the following installation changes from the previous minor version to version 1.18.

  • No installation changes are currently reported.

🌟 New features

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

AI Gateway

Starting in Gloo Gateway Enterprise version 1.18.0, you can now use Gloo Gateway’s AI Gateway capabilities. AI Gateway unleashes developer productivity and accelerates AI innovation by providing a unified API interface that developers can use to access and consume AI services from multiple Large Language Model (LLM) providers. Because the API is part of the gateway proxy, you can leverage and apply additional traffic management, security, and resiliency policies to the requests to your LLM provider. This set of policies allows you to centrally govern, secure, control, and audit access to your LLM providers.

With AI Gateway, you have access to the following capabilities:

  • Centralized credential management
  • Access control
  • Prompt enrichment
  • Prompt guards
  • Rate limiting
  • Retrieval augemented generation (RAG)
  • Semantic caching

For more information, see About AI Gateway and the AI Gateway Tutorials.

ARM images

In Gloo Gateway Enterprise, ARM images are now supported for Gloo Gateway components. An image that is tagged with -arm is compatible with ARM64 architectures. Note that ARM images are currently not supported for the Gloo AI gateway, and ARM binaries are not currently published for VMs.

AWS Lambda service account and cross-account access

The AWS Lambda integration for Gloo Gateway is now expanded to include support for the following features:

Direct response support

You can use the DirectResponse custom resource to directly respond to incoming requests without forwarding them to services. The DirectResponse resource lets you set up a pre-defined response body and HTTP status that you want to return to the client.

For more information, see DirectReponse.

JWT policies for routes

Now, you can apply JWT policies to specific routes by configuring the jwtProvidersStaged settings in the RouteOption resource. Previously, JWT policies applied at the gateway level and were configured in only the VirtualHostOption resource. With this new feature, you can apply JWT policies at both the route and gateway level. For more information and example steps, see Add JWT policy to routes.

Kubernetes 1.30 and 1.31 support

Starting in version 1.18.0, Gloo Gateway can now run on Kubernetes 1.30 and 1.31. For more information about supported Kubernetes, Envoy, and Istio versions, see the version support matrix.

Portal

Gloo Portal for Gloo Gateway Enterprise introduces many new capabilities, including new custom resources to support advanced auth use cases and a refreshed sample React frontend app to support user self-service.

For more information, review the following guides:

  • Secure Portal APIs, with information about the new PortalGroups resource for authorization and how to set up an IdP for authentication.
  • Set up a portal frontend, with information about how to deploy, secure, and prepare the sample React frontend app for user self-service.
  • Use the frontend, with information for end users about how to create their own Teams, Apps, Subscriptions, and OAuth credentials or API keys.

TCP routes

Now, you can set up a TCP listener on the Gateway resource. Then, you can create TCPRoutes to manage TCP traffic. For more information and example steps, see the TCP listeners guide.

VirtualDestination support

You can now route traffic to a Gloo Mesh Enterprise VirtualDestination directly by using the Hostname backendRef in your HTTPRoute. VirtualDestinations allow you to define unique internal hostnames for services that are spread across a multicluster service mesh. Without VirtualDestinations, you must update the IP addresses of your services every time the IP address changes, such as when you update your app or deploy a new version. Because a VirtualDestination uses labels to select the backing services, it can automatically detect IP address changes and update them for you.

To learn how to use VirtualDestinations, see VirtualDestinations.

Front channel logout

You can configure a front channel logout path on an AuthConfig that configures OIDC authorization code for your apps.

Front channel logout is a security mechanism that is used in the context of Single Sign-On (SSO) and Identity and Access Management (IAM) systems to ensure that when a user logs out of one app or service, they are also automatically logged out of the Identity Provider (IdP) and therefore all related apps and services in a secure and synchronized manner. Without front channel logout, the user is logged out of the requested app only.

For more information, see Front channel logout.

🔄 Feature changes

Review the following changes that might impact how you use certain features in your Gloo Gateway environment.

Envoy stats name changes

The stats name format for Envoy clusters that correspond to Kubernetes Services or Upstreams of type kube changed as follows:

Destination typeStats name format
Kubernetes servicekube-svc_upstreamName_upstreamNs_svcNs_svcName_svcPort
Upstream of type kubekube-upstream_upstreamName_upstreamNs_svcNs_svcName_svcPort

Other destination types continue to use the old stats format, which defaults to the cluster name, such as upstreamName_upstreamNs.

Policy overrides

Starting in version 1.18.1, you can now allow child HTTPRoutes to override policies that were set on a parent HTTPRoute by using the delegation.gateway.solo.io/enable-policy-overrides annotation. Previously, all policies that were defined on the parent were automatically inherited by all children along the delegation chain. Now, if you set the delegation.gateway.solo.io/enable-policy-overrides annotation, a child can choose to override a parent policy. A child HTTPRoute can still augment the policies that are set on a parent by defining other top-level policies that were not already set on a parent.

For more information and an example configuration example, see Policy overrides.