See what makes Kong the fastest, most-adopted API gateway
Check out the latest Kong feature releases and updates
Single platform for SaaS end-to-end connectivity
Enterprise service mesh based on Kuma and Envoy
Collaborative API design platform
How to Scale High-Performance APIs and Microservices
Call for speakers & sponsors, Kong API Summit 2023!
8 MIN READ
Kong Gateway 3.0 is an important milestone that introduces the next evolution of our cloud-native API platform. Both the enterprise and open source editions of Kong Gateway 3.0 are available now from your favorite distribution channels.
With Kong Gateway 3.0, we are introducing many powerful features that deliver following key benefits:
Let’s take a look at the top features in this release.
Understanding how Kong Gateway is performing is a key part of any deployment, and we’re excited to announce extensive tracing support in both Kong Gateway OSS and Enterprise. There are two ways to get started. You can use the out-of-the-box OpenTelemetry plugin to send OTel spans directly to any compliant backend, or to an OpenTelemetry collector. I’ve been testing Kong Gateway with Honeycomb, and it just works!
Here’s a trace that proxies a single request to mockbin.org:
Figure 1: Trace that proxies a single request to mockbin.org
Then the same request once the Rate Limiting plugin (using a Redis backend) has been enabled:
Figure 2: Same request with Rate Limiting plugin enabled
The second option is to use Kong’s tracing Plugin Development Kit (PDK) to hook into all the key events. This is how the OpenTelemetry plugin works, and it gives you complete control over how you collect and sample tracing information and how you export that data to other systems.
Whichever option you choose, understanding how Kong Gateway is performing is key. Identifying where time is being spent on each request can help you optimize for higher performance which results in happier users.
We’re shipping two brand new WebSocket plugins in Kong Gateway 3.0, in addition to a Plugin Development Kit (PDK) that allows you to build your own WebSocket plugins.
The first brand-new plugin validates your WebSocket frames to ensure that they are formatted correctly using JSON schema. You can validate frames coming from the client, as well as frames being sent back to the client from the upstream.
# Require a ‘message’ key in the payload that’s a string curl localhost:8001/routes/ws-validator-route/plugins -d name=websocket-validator -d config.client.text.schema='{"type":"object","properties":{"message":{"type":"string"}},"required":["message"]}' -d config.client.text.type="draft4"
The second plugin enables you to limit the size of the frame from both the client and the upstream. This allows you to protect your APIs and users from receiving frames that are too large and could potentially crash your applications.
# Limit frames to 4kb curl localhost:8001/routes/ws-framesize-route/plugins -d name=websocket-size-limit -d config.client_max_payload=4096
This beta release is just the beginning for deep WebSocket support in Kong, and we’d love to hear what you think on Kong Nation.
We originally launched Secrets Management in Kong Gateway 2.8 as a beta, and we’re happy to announce that it has graduated to full support status in this release.
Secrets Management allows you to store sensitive information securely in external vaults (environment variables for OSS, AWS Secrets Manager and HashiCorp Vault for Enterprise) which Kong can access at runtime. By storing sensitive values as secrets, you can ensure that they are not visible in plaintext through the platform, in kong.conf or in declarative configuration files, logs or the Kong Manager UI.
In addition, using vault secrets allows you to have specific values for development, staging and production environments while using the exact same declarative configuration file to configure each environment.
Getting started with Secrets Management is easy! Anywhere that you’d previously set a password in plain text, replace it with a vault path such as:
{vault://hcv/redis/password}
Kong will detect the reference and resolve it securely for you at runtime.
To dive deeper into Secrets Management, stay tuned to our upcoming blog which will walk you through how to store Redis password in HashiCorp Vault when using the Proxy Cache Advanced plugin.
If the words “Federal Information Processing Standards” mean anything to you (which they should if you work in government or the financial services industry), then you’ll be interested in this feature. Kong Gateway now provides a BoringSSL based build, which makes the core FIPS 140-2 compliant.
We’re currently updating all our plugins to be FIPS compliant too – please reach out to us to learn more about specific plugins.
Plugins are at the heart of Kong Gateway, and deciding the order in which to apply plugins is a tough challenge. Should rate limiting run before authentication? Should you be able to run a request transformation before checking the rate limit?
Every team has different needs, so in Kong Gateway 3.0 we’re giving you the flexibility to decide the order in which your plugins will run. We’ll set reasonable defaults, but if you want to run rate limiting before authentication to prevent brute-force attacks, all it takes is one additional piece of configuration:
curl -i -X POST http://localhost:8001/plugins \ --data name=rate-limiting \ --data config.minute=5 \ --data config.policy=local \ --data ordering.before.access=key-auth
You can order plugins by providing the name of the plugin that should run before or after, and the order can be defined using the Admin API or in your declarative configuration file with decK.
This new feature is a bit technical, so bear with us! Kong Gateway 3.0 ships with a brand new “expression” routing engine that you can use to route requests to your upstream APIs.
Imagine that you want to route GET and POST requests, but only if they’re HTTP requests. Instead of configuring routes using JSON, you can write an expression that looks like the following:
net.protocol == "https" && (http.method == "GET" || http.method == "POST")
This is a simple example, but imagine that you want to route requests that match specific hosts, and contain headers that contain the hostname. That’s hard to imagine, so let’s take a look at what it would look like:
(http.host == "example.com" && http.headers.x_example_version == "v2" ) || (http.host == "store.example.com" && http.headers.x_store_version == "v1")
This route will only match if the host is example.com and the x-example-version header is equal to v2, or the host is store.example.com and the x-store-version header is equal to v1. This is a great example of the flexibility of Kong Gateway 3.0’s new routing engine. Achieving the same behavior in 2.x would require you to create two separate routes.
Not only is the new router more expressive, it’s also more performant! Large routing configurations can now be reloaded incrementally instead of rebuilding the whole router each time there is a configuration change. This has reduced P99 time from 1.5s to 0.1s in our testing.
Finally, a word on the JSON router from 2.x. It’s still here, and it still works! We know you have existing routing rules that we need to support, so we’ve kept the existing router in 3.0. You can set router_flavor to traditional in kong.conf and things will continue to work just like in the 2.x series.
We’ve revamped Kong Manager in 3.0, making core Gateway entities such as Service, Route, Consumer and Plugin configuration more intuitive. Understanding how an entity is configured is now presented front and center rather than being hidden behind a “View Config” button and is fully editable within the same view.
Figure 3: Configuration updates
Empty states have been updated to make it easier to get started, tooltips have been added to explain configuration options and it’s now harder to accidentally delete a service or plugin.
Figure 4: Tooltips to explain configuration options
Last but not least, service overview dashboards have been revamped to provide even more information whilst making it more user friendly. You can now see at a glance the number of API services you provide, how many requests have been made and the breakdown of HTTP status (including % error rate) right on your dashboard. In addition, there’s a new “License expiration” widget to make sure that you’re never caught off guard by an expired license.
Figure 5: Updated Overview Dashboard
This is just the beginning of our work on Kong Manager, so stay tuned for even more upgrades in Kong Gateway 3.1 and beyond.
Kong’s commitment to stability means that we maintain backwards compatibility throughout all of the releases within a major version. Kong Gateway 3.0 gives us the opportunity to deprecate some functionality and remove other functionality to increase the quality of the product.
Here are the items that have been deprecated or removed:
For a complete list, see the Kong Gateway changelog.
This post is getting long, but before we wrap up I’d like to touch briefly on the remaining enhancements that we shipped in this version:
For a full list of features, fixes and updates, please see the available CHANGELOG for Kong Gateway here and Kong Gateway OSS here.
Get started with Kong Gateway 3.0 today – both the commercial and open source editions are available as a free download! If you have Kong Gateway installed already, upgrading to 3.0 is easy – check out our upgrade guide.
Share Post
Learn how to make your API strategy a competitive advantage.