Today, we are welcoming another noteworthy advancement of the Kong Gateway - the general availability of *version 2.7! *Both Kong Gateway and Kong Gateway OSS version 2.7 downloads are available on your favorite distribution channels.

This release of the Kong Gateway includes a number of important features that serve as a foundation for addressing three key areas:

• - **Scale **– Managing groups of API consumers at scale, and exposing these groups as "API tiers".
• - **Security **– Securely storing secrets (used across Gateway operations and plugins) to keep vitally important keys safe from unauthorized use.
• - **Compliance **– Enabling organizations to leverage Kong as a future-proof technology that is on its way to achieving FIPS compliance.

This release of the Kong Gateway 2.7 introduces new capabilities that significantly move the ball forward across all these three areas. Through the rest of this post, we will walk through each of these areas and explore what is new in this Kong Gateway 2.7 release. We will also be talking about new productivity improvements introduced in the Kong Manager UI for configuring our most popular plugin, the [Kong OpenID Connect (OIDC) Plugin](https://docs.konghq.com/hub/kong-inc/openid-connect)Kong OpenID Connect (OIDC) Plugin.

## Scale – API Consumer Groups Enterprise

Many users deploy the Kong Gateway to protect their APIs. Protection can take many forms, such as authentication, authorization, rate limiting, IP range restrictions or other mechanisms. The ability to enforce protections like these on a *group basis* has been one of the more consistent requests we’ve had.

For example, a developer may want to create “tiers” of users (or “consumers”) like “gold,” “silver,” or “bronze” - each having different rate limits. While this has been possible in the Kong Gateway for some time by attaching the particular rate limiting configuration to each consumer in the given tier, this approach has been limited in its capabilities.

Starting in Kong Gateway 2.7, we’re introducing a formal notion of groups of consumers or ["consumer groups"](https://docs.konghq.com/gateway/2.7.x/admin-api/consumer-groups/reference)"consumer groups". Now you can assign a consumer to a “gold tier” group or a “silver tier” group and then give each of those tiers a rate limiting configuration like “10 requests per second,” effectively making rate limits applicable on a collection/group of consumers. You would then assign those groups to particular routes/services in your gateway configuration.

A consumer can also be assigned to multiple groups. This means that you can assign a user to a group like “gold with 10 requests per second" for QR code generation service (“gold_limited_light_cpu”) and also to a group like “silver with 2 requests per minute" for OCR (“gold_limited_heavy_cpu”), and then split your APIs to use each of those groups. Check out the diagram below:

Diagram 1: Consumer Groups for Rate Limiting Advanced Plugin

This new functionality simplifies your configuration by centralizing related consumers in one place and also increases performance of the Kong Gateway by creating related consumer groups in the database or declarative config. For more information, have a look at the [consumer groups examples](https://docs.konghq.com/gateway/2.7.x/admin-api/consumer-groups/examples)consumer groups examples. The rate limiting advanced plugin instance is our first step in the direction of consumer groups. In the future, we expect to expand this functionality to other plugins as well, so stay tuned!

## Security – Secrets Management Enterprise

A secret is anything we use as a set of credentials for authentication and authorization for Kong Gateway operations or in plugin configurations. Some examples of secrets might include user names/passwords, API tokens, database credentials, private keys. From the operator's perspective, sensitive information like this should be kept safe from unauthorized use and stored in an encrypted format where required. With Kong Gateway 2.7 we've made several additions in this area, including:

• - Extended the [Keyring & Data Encryption mechanism](https://docs.konghq.com/gateway/2.7.x/plan-and-deploy/security/db-encryption/#main)Keyring & Data Encryption mechanism to ensure [more plugins and their associated configuration](https://docs.konghq.com/gateway/changelog/#plugin-encryption)more plugins and their associated configuration (which may contain secrets) can make use of the mechanism's encryption of data at rest. In other words, more plugins can have their secrets safeguarded.
• - Ability to encrypt the config.cache.json.gz configuration cache at rest for data planes in Kong's hybrid deployment mode. Check out the [new setting](https://docs.konghq.com/gateway/2.7.x/reference/configuration/#data_plane_config_cache_mode)new setting in kong.conf called data_plane_config_cache_mode - setting this to ‘encrypted' stores the config cache securely and can be opted into.

## Compliance – Path towards FIPS Compliance Enterprise

We've started replacing the cryptographic foundations in Kong Gateway, by swapping the primary library in the Gateway (OpenSSL) with a library that's FIPS 140-2 validated (BoringCrypto aka BoringSSL) and distribution as an Enterprise-only build will begin in the new year. This is a step toward becoming FIPS 140-2 compliant, and more are planned!

### And Another Addition! Enterprise

Identifying the minimum set of configurations required for getting started with OpenID Connect can be quite a challenging task, especially for developers who are new to the protocol. In version 2.7, Kong Manager now provides a more streamlined and organized approach for configuring the OIDC Plugin with Kong Gateway. By exhibiting the most common ways to get set up and running with OIDC (while still having the ability to add more custom configurations as needed), you can more quickly build single sign-on with an identity provider. For more information about working with OpenID Connect and Kong's OIDC Plugin head over to our documentation [here](https://docs.konghq.com/gateway/2.7.x/configure/auth/oidc-use-case)here.

Diagram 2: New and Improved OIDC Plugin Configuration

### Explore More to the Release

• - New support for routing [TLS traffic based on SNIs](https://docs.konghq.com/gateway/2.7.x/reference/proxy/#proxy-tls-passthrough-traffic)TLS traffic based on SNIs - also known as SNI Proxy
• - Kong Gateway is now available on [Debian 10 and 11](https://docs.konghq.com/gateway/2.7.x/install-and-run/debian)Debian 10 and 11
• - When using [OpenID Connect to secure Kong Manager](https://docs.konghq.com/gateway/2.7.x/configure/auth/kong-manager/oidc-mapping)OpenID Connect to secure Kong Manager admins are now created on first login and roles assigned based on their group membership.
• - In this release we continued to work on performance with improvements to the plugin iterator, simplifying Kong core context reads/writes, reducing latency on reloading DB-less configs.

A full list of features, fixes and updates to [Kong Plugins](https://docs.konghq.com/gateway/changelog/#plugins)Kong Plugins are available in the CHANGELOG for Kong Gateway [here](https://docs.konghq.com/gateway/changelog)here and Kong Gateway OSS [here](https://github.com/Kong/kong/blob/master/CHANGELOG.md)here.

Kong Gateway 2.7 is available today as a [free download](https://konghq.com/install)free download - for fresh/clean installs! Let us know what you think on [Kong Nation](https://discuss.konghq.com)Kong Nation. If you have the Kong Gateway installed already, you can upgrade to 2.7 by following the [upgrade guide](https://docs.konghq.com/gateway/latest/install-and-run/upgrade-enterprise/#main)upgrade guide. To learn more about this release, join us for the [upcoming webinar](https://konghq.com/webinars/protect-apis-services)upcoming webinar.

The production of Kong Gateway releases is only made possible by the cosmic amount of collaboration from Kong employees, customers and community members. Your active support in making this release a success deserves a big **Thank You!**

*Note: *[*Shane Connelly*](https://konghq.com/blog/author/shane)*Shane Connelly** also contributed to this post.*