Figure 1: Secrets Management 

OpenID Connect: Token security with sender-constrained access tokens

In token-based systems, access tokens grant access to resources. In this process, the legitimacy of the token bearer is assumed and access is granted based on token validity. A major security challenge with this approach is the lack of checks to ensure the legitimacy of the token bearer as unauthorized access can be easily obtained with stolen or leaked tokens. This is a major concern for any API provider, especially for those environments with heightened security needs. The solution to this problem is to restrict the tokens to clients (sender-constrained access tokens) so only the entity to whom a token was issued can use it to access the requested resources. This is achieved by the authorization servers binding the tokens to cryptographic keys and resource servers requiring the clients to prove the possession of those keys to grant or deny access accordingly. 

Kong Gateway Enterprise 3.5 offers sender-constrained tokens via mTLS. The tokens issued by the authorization server are bound to the client certificates used to establish the connection. The resource servers validate the certificate thumbprint in the tokens to the underlying mTLS connection and grant access to the resources. This feature is enabled using OIDC and mutual TLS plugins and is available for bearer token and introspection authentication methods in the OIDC plugin. 

With sender-constrained access tokens using mTLS, we’ve provided an additional layer of security for access tokens and enable you to mitigate the risk of misuse of tokens. 

Stronger native AWS feature support: AWS Secrets + DP Resiliency

As part of the 3.5 release, we’ve expanded our native AWS support for two key features, the AWS Secrets Manager integration and the Data Plane Resiliency feature, which can work with AWS S3.

On the Secrets Manager front, we’ve added `assumeRole` capability for this integration. This means that Kong can temporarily assume a different AWS IAM role in order to fetch secrets from AWS Secrets Manager. This is commonly used in scenarios where the Secrets Manager is in a different VPC/deployment where Kong is running. AssumeRole behavior is used for cross-account communication. And because the behavior is short-lived, it’s considered very secure. This gives teams the ability to adhere to secure best practices offered within the AWS ecosystem.

Our Data Plane Resiliency feature works by backing up the Kong Control plane configuration into S3. A special type of Data Plane, called a `backup_node` will receive configuration from a Control Plane and push that configuration to an S3 compatible bucket. If the Control Pne ever goes down, the other Data Planes can be configured to reach out to this bucket to grab the last available configuration if needed.

By default, AWS S3 will encrypt any object before storing it on disk, with a default AWS key if none is specified. For many organizations, that isn’t sufficient, as they may have policies with regard to how long a key is valid for, which certificate authority (CA) it’s signed by, and which encryption algorithms are being used.

To that end, in 3.5, we’ll allow the users to specify which Amazon Key Management System (AWS KMS) key to use when encrypting the configuration prior to storage into S3. This gives users the flexibility to adhere to an organization’s internal security policies and not rely on any default behavior.

Kong’s native integrations with AWS will continue to reduce friction in AWS environments and empower teams to conform to AWS best practices with ease.

Kong Manager gets a brand new makeover

As a part of the 3.5 release, we applied a new redesign to the Kong Manager UI. 

Previously, the UI/UX of Kong Manager, Kong Konnect, and Kong Manager OSS were all distinct from each other. As a part of the 3.5 Gateway Release, we’ve unified the UI components to give each of them a similar look and feel for a smoother user experience. To make navigation simpler, we’ve unified the menus into one sidebar and removed an additional layer that required users to click extensively to navigate through the UI. 

All functionality from the previous UI is still intact, so you can enjoy the new UI without compromising any of your previous workflows.

Extended policy support for Consumer Groups

In Gateway 3.4, we released Consumer Groups for the first time, with the ability to configure Rate Limiting policies on top of them.

As a part of the 3.5 release, we’re happy to announce that the policies you can apply on Consumer Groups have been extended to include the Request Transformer plugin, Request Transformer Advanced plugin, Response Transformer plugin, Response Transformer Advanced plugin, and any custom plugins.

Feel free to unlock the power of consumer groups with these additional policies today.

Next steps

Begin your journey with Kong Gateway 3.5 by signing up for Kong Konnect, for free!

If you’re interested in Kong Gateway Enterprise 3.5 you can download it for free here. To explore the comprehensive list of features, fixes, and updates, please see the available CHANGELOG for Kong Gateway Enterprise here and Kong Gateway OSS here.