Kong Gateway 2.4 Now Generally Available!
← Back to Blog Home
Note to readers before we get started: you’ll see us referring to the “Kong Gateway” in this post. This is the product previously referred to as Kong Gateway Enterprise. In version 2.3, we released a free operating mode of Kong Gateway Enterprise, and given it no longer needs a paid “Enterprise” license, we now refer to this gateway as the Kong Gateway and disambiguate from the OSS-only Gateway as Kong Gateway (OSS).
Support for “db-less” Installation
Sometimes, as the saying goes, “less is more.” Starting in version 2.4, Kong Gateway officially supports “db-less” or a fully declarative configuration should you desire to run in that mode. To be clear, KIC — our Kubernetes Ingress Controller has allowed users to run without a separate database for a while and there’s nothing that stopped users from running the Gateway in a declarative mode before 2.4. But starting in 2.4, we’ve done enough testing to give it our official seal of approval.
Note that there are still some places — notably a few plugins as well as our UIs like Kong Manager and developer portal — that do require a database to store information, so if you need those, you’ll want to stick with a database backed install.
Also, the keyring and data encryption feature works with a database and if you’re an enterprise customer and want to monitor your license usage, that’s held in a database so you’ll want to monitor it with other mechanisms if you decide to go db-less.
Finally, much of the admin API is disabled when operating in db-less: for more details, have a look at the docs here.
Plugins and Plugin Frameworks
As we pointed out on the Kong Gateway (OSS) 2.4 release blog, we’ve added a powerful new capability to our logging plugins to allow users to format them by defining arbitrary transformation functions. This means you can drop fields you don’t need, rename fields to names you like better, and even perform calculations like determining whether response times met business SLAs directly before logging out. This new functionality has been added to the file-log, Loggly, Syslog, tcp-log, udp-log and http-log plugins.
For those unfamiliar, Open Policy Agent, or OPA, is a graduated CNCF project. It’s a fantastic way to define authorization policies for microservices using a very flexible policy language called Rego. You can quickly create authorization rules that are as sophisticated as your business: mixing concepts of things like your network and user/group topologies to inform authorization decisions.
OPA’s flexibility and cloud-native approaches are both why it’s quickly gained a ton of traction among a broad user base and also why it’s a great fit together with the Kong Gateway.
Kong’s new OPA plugin allows the Kong Gateway to make authorization policy decisions dynamically by interacting with an OPA runtime. Upon handling a request, the Gateway can submit information like the route, consumer, and/or service information to OPA and get back an allow/deny response and take the appropriate action in the gateway.
The OPA Plugin is a Konnect Enterprise license level plugin: customers can try it out and let us know what you think!
Mocking is a powerful tool in the world of APIs by allowing users to test their code against virtual implementations of APIs before they roll out any code. That leads us to a new feature that Kong Gateway 2.4 brings: a new Mocking plugin that allows you to mock your API responses directly on the Kong Gateway.
Bring a Swagger v2/OpenAPI v3 specification to the Gateway’s new Mocking plugin and you can mock responses directly in the same network topology and configuration as where your APIs will ultimately reside — all without any extra tools or servers.
The Mocking Plugin is a Konnect Enterprise license level plugin: customers can try it out and let us know what you think!
Hybrid Mode Version Compatibility
Finally, one more “big” feature in 2.4 is much better version compatibility between the control plane and remote data planes in hybrid mode. Prior to 2.4, we did our version compatibility checks at connection initiation, which meant that incompatibilities in the data plane (e.g. missing plugins that the control plane knew about) were enforced even if those plugins weren’t being used by the configuration at all.
We’ve now switched the check to happen at configuration read time: if you’re not using features that the data planes don’t know about (because they aren’t using a version that contains that feature), they can still happily read from a control plane of a more recent version.
This should give everyone operating in a hybrid mode architecture — including those using our SaaS product, Konnect — a much better upgrade experience.
Try Kong Gateway 2.4 Today!
We’re thrilled to be able to share this latest release with you, and we’re proud of the contributions from Kong employees, our awesome customers and our great community! This is just a small sample of what is new in 2.4: for a full list of changes, have a look at our Changelog.
Try Kong Gateway 2.4 today