We're delighted to announce the release of Kong Gateway 3.4 for [Kong Enterprise](https://konghq.com/products/kong-gateway)Kong Enterprise and [Kong Konnect](https://konghq.com/products/kong-konnect)Kong Konnect, featuring significant enhancements, such as secrets rotation support in secrets management, expanded plugin support in consumer groups, and more.
The highlight of this update is the designation of Kong Enterprise 3.4 as a [Long Term Support (LTS) release](https://docs.konghq.com/gateway/latest/support-policy/#supported-versions)Long Term Support (LTS) release. Starting now, any customer running Kong Enterprise version 3.4.x.x will receive technical support for *three *years — until 2026. This follows our announcement of [Kong Enterprise 2.8](https://konghq.com/blog/product-releases/kong-enterprise-2-8-lts-support)Kong Enterprise 2.8 as an LTS version of Kong.
Additionally, all the Kong Gateway 3.4 for OSS features are also included in Kong Enterprise. Check out [this post](https://konghq.com/blog/product-releases/gateway-3-4-oss)this post for a comprehensive OSS update.
In this post, we'll explore the Kong Gateway 3.4 advanced features available exclusively to our Kong Enterprise and Kong Konnect customers.
## Streamlined configuration management with Consumer Groups GA
As businesses grow and expand their set of products and services, it's extremely common to segment their offerings into ‘tiers', ‘packages', or ‘levels'. Within any given ‘tier', all subscribed users should have the same experience, features, and limits.
A user is subscribed to a tier, and their product journey is dictated by the attributes of that tier. This could include limits or quotas on consumption, and sometimes even different UI/UX on a per-tier basis.
To keep things simple, any update to the tier definition is applied only at the tier level, never to an individual user. This keeps tier logic separate from user logic, reducing the need to rewrite the tier definition for every user.
In Kong Gateway verbiage, we represent the user with the [Consumer](https://docs.konghq.com/gateway/latest/kong-manager/get-started/consumers/)Consumer entity, and the tier with the [Consumer Group](https://docs.konghq.com/gateway/latest/kong-enterprise/consumer-groups/)Consumer Group entity.
Today, enterprise customers can use [Consumer Groups](https://docs.konghq.com/gateway/latest/kong-enterprise/consumer-groups/)Consumer Groups to place their consumers into ‘tiers' based on some identifier, like ‘plan type' or ‘subscription level' and place limits on rate using the [Rate Limiting Advanced](https://docs.konghq.com/gateway/latest/kong-enterprise/consumer-groups/)Rate Limiting Advanced plugin. This powerful feature helps group similar consumers into a single configuration, which can dramatically reduce the number of Rate Limiting plugins that need to be configured.
In 3.4, we're extending Consumer Group support to the [Request Transformer](https://docs.konghq.com/hub/kong-inc/request-transformer/)Request Transformer, [Request Transformer Advanced](https://docs.konghq.com/hub/kong-inc/request-transformer-advanced/)Request Transformer Advanced, [Response Transformer](https://docs.konghq.com/hub/kong-inc/response-transformer/)Response Transformer, and [Response Transformer Advanced](https://docs.konghq.com/hub/kong-inc/response-transformer-advanced/)Response Transformer Advanced plugins. The Rate Limiting Advanced plugin will continue to be supported with Consumer Groups.

*Figure 1: Consumer Groups for Request and Response Transformation advanced plugins*
Our goal with this expansion is to offer more features to support the ‘tiering' use cases and to simplify gateway configuration by making them available at the Consumer Group level rather than at the Consumer level.
Please note that adding more support for Consumer Groups means we had to change the way it currently works with the Rate Limiting Advanced plugin. The current method will still work, with the addition of a few small changes that will be required to harness the full potential of Consumer Groups and the larger set of plugins. We outline these changes [here](https://docs.konghq.com/hub/kong-inc/rate-limiting-advanced/changelog/)here.
## Secret rotation: Enhancing security and flexibility GA
The management of secrets — or sensitive material like certificates, passwords, and authentication tokens — is a major focus for enterprises today. A myriad of impressive tooling has been developed to keep this sensitive information safe and away from prying eyes. As Kong Gateway represents an important networking component, at the intersection of public and private services and networks, it requires certain sensitive information, like certificates and certain credentials, to function properly.
It's no accident that Kong Gateway boasts a wide set of integrations with [secrets management tools](https://docs.konghq.com/gateway/latest/kong-enterprise/secrets-management/)secrets management tools. This allows a user to pass a reference for a value in their gateway config, which will later be dereferenced by the chosen secrets manager integration. Practically speaking, this means you don't have to put sensitive information into your Kong Gateway config. This fulfills the enterprise compliance goal of not requiring the Kong operator to handle sensitive information, but still providing Kong Gateway the required information to operate as your API gateway.
Another major component of secrets management is the *lifecycle *of the secrets themselves. What happens when a certificate expires? What if we have a policy to change our password every three months? What about authentication tokens that have a very short time to live (TTL) duration and generally expire in 24 hours?
In this release, we're expanding our wide support for secrets management integrations by complying with secrets lifecycle requirements. Starting with 3.4, each secret can have an associated [time to live duration](https://docs.konghq.com/gateway/latest/kong-enterprise/secrets-management/secrets-rotation/)time to live duration (or TTL) which tells Kong Gateway how long this secret can be used before the gateway should request the Secrets Manager to update this information.
Essentially, the TTL acts like a countdown timer, and once the timer expires, Kong Gateway will retrieve the secret referenced in the configuration. In the event there's no change in the value of the secret, Kong Gateway will continue to use the value it has.

*Figure 2: Secrets rotation support *
With this feature, customers can easily conform to the security and compliance requirements of their organization.
## Empowering event-first architecture with Kong Enterprise and Kafka plugins GA
In the realm of modern enterprise architectures, the event-first approach is gaining momentum for its ability to foster seamless collaboration across diverse teams. This approach hinges on the principle that data, in its purest form, should be the only coupling factor among teams — eliminating the need for shared libraries, synchronized release schedules, or common tooling.
Kong Enterprise, with its robust support for [Kafka Log](https://docs.konghq.com/hub/kong-inc/kafka-log/)Kafka Log and [Kafka Upstream](https://docs.konghq.com/hub/kong-inc/kafka-upstream/configuration/)Kafka Upstreamplugins**,** is designed to address these challenges head-on. Our Kafka plugins offer strong support for Kafka, which is known for its reliability, performance, and real-time capabilities.
Kafka is often a cornerstone of many enterprise architectures, and we're thrilled to introduce significant Kafka Plugin enhancements in our latest release. These enhancements are specifically tailored to enable event-first architecture, transforming Kong Enterprise into a powerful event gateway.
Transforming data prior to publishing it to a Kafka topic is a common business requirement. This is due to the fact that data you seek to publish may contain personally identifiable information (or PII) and therefore it is mandated to reside in the local region. In such cases, you want to transform or redact certain fields as needed. Kong Enterprise is excited to support this use case in 3.4.
Starting in this release, the `custom_fields_by_lua` function is now supported in our Kafka Log plugin. This allows you to execute arbitrary logic across the payload and customize the log format, which can include the transformation of specific values, such as PII. This behavior is already supported in other plugins like [File-Log](https://docs.konghq.com/hub/kong-inc/file-log/#custom-fields-by-lua)File-Log.
## Meeting our users where they are: RHEL9 support comes to Kong Enterprise 3.4 LTS
Red Hat Enterprise Linux (RHEL) is one of the most popular Linux distributions for Kong Enterprise. Our customers love RHEL because of its unmatched support, frequent updates, and long lifecycle. In 3.4, we're announcing support for [RHEL9](https://docs.konghq.com/gateway/latest/support-policy/#supported-versions)RHEL9 in addition to RHEL7 and RHEL8.
Before releasing a new LTS version of Kong Enterprise, we wanted to invest in the distributions our customers will be with for the long term. Many of our users are in the process of upgrading to RHEL9, and we're committed to being there every step of the way to provide a seamless transition.
Lastly, we'll be supporting a diverse set of requirements with RHEL9, including builds for ARM64 architecture and FIPS builds for customers who work with U.S. government entities.
### Next Steps
[Sign up for Kong Konnect](https://konghq.com/products/kong-konnect/register)Sign up for Kong Konnect for free and get started today with Kong Gateway 3.4!
If you're interested in Kong Enterprise 3.4 you can download it for free [here](https://konghq.com/install)here. If you have Kong Gateway installed already, upgrading to 3.4 is easy — just check out our [upgrade guide](https://docs.konghq.com/gateway/latest/upgrade/#main)upgrade guide. For a full list of features, fixes, and updates, please see the available CHANGELOG for Kong Enterprise [here](https://docs.konghq.com/gateway/changelog/)here and Kong Gateway OSS [here](https://github.com/Kong/kong/blob/master/CHANGELOG.md#340)here.
*Note: The Beta release of Wasm in *[*Kong Gateway 3.4 for OSS*](https://konghq.com/blog/product-releases/gateway-3-4-oss)*Kong Gateway 3.4 for OSS** will not be covered by LTS support. The Wasm module is dynamic and is disabled by default. We do not recommend running Wasm in production as it is in beta. We will be unable to support LTS customers who have activated the Wasm module in production. Wasm is currently not supported in Kong Konnect.*