New Gloo 1.5 with improvements to multi-cluster failover, traffic control, AWS Lambda, external Auth, and dev-to-ops experience

Solo.io | October 01, 2020

Today we released Gloo 1.5, the latest release of our Envoy Proxy based API Gateway. We’ve been working closely with our enterprise and open source customers to deliver new features, enhance functionality, and fix issues. Since the last Gloo release, we’ve also added Gloo Federation to scale API gateway deployments, and in this release we continue innovating on the gateway, federation, developer portal, and more. Attend the upcoming webinar to get a demo of the latest release.

Highlights of this release include:

Enhanced Multi-Cluster Failover in Gloo Federation
Traffic Routing and Route Table Enhancements
More Config Options for Gloo, Envoy, and a Dry-Run Validation API
Security Improvements for External Authentication
Improvements for Configuring and Enforcing Rate Limits
Enhanced AWS Lambda Integration
Developer and Operator Experience

Federation Enhancements to Multi-cluster operations

This summer we introduced Gloo Federation to help organizations scale their API gateway operations across multiple clusters with consistent configuration and traffic management. A key use case for Gloo Federation is the ability to leverage failover routing and in this release we’ve added DNS resolution to failover endpoints (#3565) and added the following Helm chart values to configure the proxy for failover, adding Secrets containing downstream SSL secrets, define port to use for failover bind port and service, and to configure an optional NodePort for the failover service (#3338).

The following updates to the glooctl CLI improve the Gloo Federation end user experience to include the ability to bootstrap a multi-cluster demo, install and uninstall Gloo Federation, detect multi cluster resources, list the registered clusters, and register or unregister a cluster to the Gloo Federation control plane (#3369).

Traffic Routing and Route Table Enhancements

At the core of an API gateway is to route and shape the traffic from external clients to the backend services. Gloo’s advanced traffic management functionality can handle simple API to API routing in addition to complex HTTP to gRPC routing with transformations. In this release we’ve made a number of enhancements across Gloo’s traffic management capabilities including allowing the cluster name to be the SNI of a TLS request when routing through a TCP proxy (#3223) and the ability to specify transformations at an earlier stage and allow response-only transformations (#3028).

Route tables have the following enhancements including: new label selector expressions (#3586), the ability to properly validate RouteTable routes without matchers (#3291), expanded route table inheritance to allow query parameter matchers, header matchers, and method matchers (#3327), a new inheritableMatchers field that changes how route delegation handles header, method, and query parameter matchers from the parent resource (#3327), and the ability to report delegation cycle errors on the offending RouteTable and not only on the VirtualServices that use the table (#3144).

More Configurations Available for Envoy Proxy and Gloo

In this release we have exposed the raw Envoy configuration for the gRPC to JSON transcoding filter for teams to have more granular control over the gRPC to JSON mappings and this can be used to expose a gRPC service both as a gRPC service and as a REST API. An example of how this can be used is for query parameter transcoding (#2188). Additionally, we now expose the Envoy cluster configuration’s common_http_protocol_options parameters in the Gloo API (#3560).

Custom labels can now be added to the Gloo Enterprise deployments (#3441), labels values can be changed for ingress proxy to allow for multiple instances in the same cluster (#3587), and also arbitrary labels for Gloo pods (#3441). Lastly, we’ve added the ability for a graceful shutdown when relying on external load balancers with the Kubernetes preStop hook, allowing Envoy to fail external facing healthchecks while still processing existing requests (#3308).

Dry-Run Requests with the Validation API

In this release we’ve made updates to the gateway validation API including the ability to now handle lists of gateway resources (#3261), accept YAML admission requests if it was sent with the application/x-yaml header (#3256), return proxies in the webhook response which may be useful to perform diffs between proxies before and after the proposed changes to the gateway resources including, virtual services, route tables, and gateways (#3257) and fixed an issue with how the API handled dry-run requests so that it no longer modifies the internal resource cache, resulting in incorrect results (#3437).

Security Improvements to External Authentication and More

Gloo’s security first design provides a variety of auth configuration options, traffic encryption, and more. Specific to the auth service, this release adds support for OAuth2 access token validation via token introspection to the extauth service, configuring the userinfo OIDC endpoint to the new access token validation API to leverage the userinfo response in extauth plugins (#3055) and the external auth service now supports TLS connections to itself using Kubernetes secrets instead of cert and key files (#3430).

If you are using API Keys in your auth flow, you can now define the API to allow adding arbitrary API key secret data to the headers of successfully authorized requests (#3385), or to allow users to change the name of the header that the external auth server inspects for API keys (#3390), and the API keys can now be provided as Kubernetes secrets instead of nested in a YAML document (#3472).

Secrets can now be added to request headers by referencing a Kubernetes secret resource via its namespace and name (#2751). Lastly we’ve updated the permissions for namespaced users to now allow them to install (#3424) and create resources in Gloo Enterprise (#1847) and fixed an issue where Istio certificates used in mTLS were not being rotated in Envoy (#3295).

Improvements for Configuring and Enforcing Rate Limits

As an API gateway, Gloo has functionality to apply rate limits to backend applications services to protect them from being overrun with requests and failing. In this release we’ve added functionality to define, apply and enforce rate limit policies using RateLimitConfig resources by applying a set of policies to VirtualHosts and Routes by referencing a set of RateLimitConfig resources. Each resource represents a rate limit policy that will be independently enforced (#3335). Refer to the docs for an explanation of the new API. We’ve also added new helm values for rate limit descriptors in settings (#3422, #2462) and global.extensions.dataplanePerProxy which will deploy a set of dataplane resources for each proxy deployment (i.e., gateway/ingress) including the extauth server and rate limit server, as well as their dependent resources (#3236).

Enhanced Integration to AWS Lambda

Gloo has always supported serverless functions with the ability to discover and access AWS Lambda services while serving as its gateway. In this release, Gloo further integrates with AWS services including the ability to discover Lambda functions using EKS Service Account credentials (#3559) and allow Gloo instances running in EKS to use AWS Service Account credentials to authenticate requests directly (#3309).

Developer and Operator Experience

This Gloo release includes enhancements to both the developer and operator experience in managing and securing APIs and their respective traffic including updates to the glooctl command line, how the system handles health checks, and overservability with added metrics and error messages.

The glooctl CLI updates include changing the glooctl cluster unregister command to glooctl cluster deregister to delete the service account, cluster role, and cluster role binding (#/3369), support a flag “-x” to exclude certain checks (#3492), new helper commands to get Gloo and Istio up and running with mTLS (#3532), and allowing glooctl to invoke arbitrary binary plugins similar to the Kubernetes plugin system (#3460).

Gloo Health checks can now reference header secrets for additional headers to add in addition to specifying them explicitly (#2914), in addition to path overrides in http health checks on a per-host basis (#2821), and we’ve corrected an issue in UDS where the Health Checks and Outlier Detection configuration were being overwritten by updated upstreams (#3216).

To enhance the observability of Gloo, we’ve added a new error message when there is an unexpected error with the ListEnvoyDetails API call (#3512), updated Envoy to emit proxy latency timings and access these logs through dynamic metadata (#3392), added a Prometheus metric to the gateway pod indicating if the validating admission webhook determined the config was valid (#3408), and corrected an issue for upstream names on auto-generated dashboards for manually-added Kubernetes upstreams. (#3061) and where OpenTracing was causing an Envoy failure (#3496).

Get Started with Gloo

In addition to the features listed in this blog, there are more enhancements and fixes we’ve made to Gloo along with contributions from the community. In particular, there’s now the ability to build Gloo for ARM64 (#3486) and while not ready for production environments, we invite you to try it out and provide feedback. Gloo is available in open source and enterprise editions addressing a wide range of edge / API gateway use cases.

Learn more:

About Gloo API Gateway
Read about the Developer Portal updates here
Request an enterprise trial
Register for an upcoming event
Join the conversation in the community slack