[Kong Gateway](https://konghq.com/products/api-gateway-platform)Kong Gateway 3.0 is an important milestone that introduces the next evolution of our [cloud-native API platform](https://konghq.com/blog/why-kong-is-the-best-api-gateway)cloud-native API platform. Both the enterprise and open source editions of Kong Gateway 3.0 are available now from your favorite [distribution channels](https://docs.konghq.com/gateway/latest/install-and-run)distribution channels.

With Kong Gateway 3.0, we are introducing many powerful features that deliver following key benefits:

• - **Enhanced Security and Governance**: Meet security and compliance requirements with FIPS 140-2 compliant Kong Gateway runtime and secure secrets storage (used across Gateway operations and plugins).
• - **Flexibility and Extensibility – **Customers can choose their plugin execution order, add native support for WebSocket traffic and leverage deep OpenTelemetry integration.
• - **Easy API Management** – New capabilities in Kong Manager UI enhancing the user experience. Introducing a powerful new routing engine that optimizes expressing complex routes while also increasing runtime performance.
• - **Significant Performance Improvements:** Compared to Kong 2.8.1.4, Kong 3.0 features more than a 37% increase in throughput and reduced latency by over 47% at the 99th percentile and 27% at the 100th percentile for high complexity routing scenarios. In this case, our memory consumption is reduced by 9%.

Let's take a look at the top features in this release.

## Tracing and OpenTelemetry EnterpriseOSS

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.

## WebSockets (Beta) Enterprise

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](https://discuss.konghq.com/?_ga=2.210371093.1089395558.1663198607-1839953283.1663198607)Kong Nation.

## Secrets Management (GA) EnterpriseOSS

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.

## FIPS 140-2 Compliance Enterprise

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.

## Plugin Ordering Enterprise

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.**

## New Routing Engine EnterpriseOSS

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.

## Kong Manager 3.0 Enterprise

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.

## Deprecations and removals

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:

• - Kong Gateway no longer uses a heuristic to guess whether a route.path is a regex pattern. From 3.0 onward, all regex paths must start with the “~” prefix, and all paths that don't start with “~” will be considered plain text. The migration process should automatically convert the regex paths when upgrading from 2.x to 3.0.
• - Support for the nginx-opentracing module is deprecated as of 3.0 and will be removed from Kong in 4.0. Use the new tracing PDK and OpenTracing module as a replacement
• - Amazon Linux 1 and Debian Jesse are no longer officially supported operating systems
• - POST requests on /targets endpoints are no longer able to update existing entities. They are only able to create new ones. If you have scripts that use POST requests to modify /targets, change them to PUT requests to the appropriate endpoints before updating to Kong Gateway 3.0.
• - High cardinality metrics are now disabled by default in the Prometheus plugin. This will decrease the load on the database when Prometheus scrapes statistics

For a complete list, see the [Kong Gateway changelog](https://docs.konghq.com/gateway/changelog/#breaking-changes-and-deprecations)Kong Gateway changelog.

## Additional Highlights

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:

• - **Plugin version alignment: **It's been tough to work out exactly which version of a plugin you're running previously. As of Kong Gateway 3.0, we're aligning the plugin version to the gateway version so that people know exactly which version of a plugin they're running
• - **Slim/UBI Images: **We've switched the base images for our Docker builds to debian-slim and rhel-ubi. This means smaller images for you, and fewer installed packages leading to a more secure image.
• - **System Certificate Authority:** Kong now uses any CA certificates installed on the host operating system by default. This allows you to manage your certificate authorities in a single place for all of your software
• - **LDAP Authentication:** Our LDAP authentication plugin lets you protect your services by authenticating against an LDAP server. Kong Gateway 3.0 adds support authorization based on group membership. You can now say "only members of the FinanceDev team can access this API".

## Get Started with Kong Gateway 3.0 Today

For a full list of features, fixes and updates, please see the available CHANGELOG for Kong Gateway[ here](https://docs.konghq.com/gateway/changelog/#3000) here and Kong Gateway OSS[ here](https://github.com/Kong/kong/blob/master/CHANGELOG.md#300) here.

Get started with Kong Gateway 3.0 today - both the commercial and open source editions are available as a[ free download](https://konghq.com/install) free download! If you have Kong Gateway installed already, upgrading to 3.0 is easy - check out our[ upgrade guide](https://docs.konghq.com/gateway/latest/install-and-run/upgrade-enterprise/#main) upgrade guide.