Kong API Gateway

Kong API Gateway: Middleware Between Compute Clients and Applications 

With the adoption of micro-services architecture, it is usually found that other patterns should be considered simultaneously. In particular, the API Gateway. It is a built-for-purpose reverse proxy to deal with restful APIs traffic before sending the request to the microservices. It protects a nominated network by creating perimeter security and an exclusive access point. 

The API Gateways can be generic traffic verifiers. However, choosing the correct API Gateway (Kong API Gateway) can create a very agile environment where the API Gateway is a fundamental piece of the security strategy. It is a model where the application security is designed and implemented on layers. The API Gateway is given many more responsibilities than the mere traffic verifier. It plays a significant role in the application and enterprise security strategy, which otherwise would have to be done in a secondary layer. It is strategically located at the perimetral network level, so the idea is to use it to do several security verifications of different kinds rather than pass the traffic stream to downstream applications. 

Security in microservices is required, but it is difficult to enforce it. One possibility is duplicating the same code for each micro-service as a shared kernel library. This model is good but could be more optimal. So, with Kong API Gateway, the authentication and authorization verifications are done by default to all APIs invocations before the traffic reaches the microservices. 

It also provides many other out-of-the-box plugins for load balancing, logging, authentication, rate limiting, request size limiting, transformation, IP allows listing, etc. It is also possible to extend these security verifications by implementing custom plugins. There is a deployment version of Kong that takes the role of Kubernetes ingress controller.  

If you are using Kubernetes architecture, it can help you take full advantage of the power of the Kubernetes framework. Generally, a Kubernetes cluster has only one ingress controller. In this case, we are defining a type of cluster secured by design since only HTTP restful APIs traffic can reach application components.  

The Kong API Gateway plugin list is extensive, including the custom-developed plugins we use in our baselined architecture framework. Below we all the add-ons provided by Kong and the others we added to the list. These are not meant to be used simultaneously but are configured accordingly, depending on the scenario.   

CORS: Cross-origin resource sharing (CORS) is an add-on that allows configuring restrictions to the original applications invoking the APIs. It controls the cross-origin HTTP requests initiated by clients that do not conform to the same domain where the APIs are deployed. If the REST’ ‘API’s resources receive cross-origin HTTP requests, they will be rejected.  

IP White-listing: This add-on allows a list of IP addresses or a range to invoke APIs. It is a valuable capability when integrating business-to-business (B2B), where the connections between systems can be predefined.   

Bot detection: It is an add-on that protects an API endpoint from being used by a Bot. it recognizes invocation patterns using the most popular algorithms used by bots. It has the capability of whitelisting and black-listing clients temporarily or permanently. JWT Validation (Local check to verify the token has not been tampered with or expired). It is an add-on that checks requests containing HS256 or RS256 signed JSON Web Tokens (as specified in RFC 7519). It confirms the existence, integrity, and expiration of the token. It is a local validation; therefore, it does not introspect the content.  

Rate limiting: It is an add-on used for configuring and validating the number of HTTP requests and the frequency of a client. It works by defining Time Windows, and these periods can be seconds, minutes, hours, days, months, or years.   

Correlation Id (Add correlation id): The correlation id field identifies every incoming request to the system univocally. From an application, perspective is used for logging, traceability, and operation support. From a security perspective, it is used for non-repudiation and auditing. The add-on verifies if the incoming HTTP Request contains the required Correlation Id. If the correlation id is not in the header, it generates a new one and adds it to the payload.  

Payload Syntax validation: It can be done using an out-of-the-box plugin or creating a custom one.  

Payload Semantic validation: It can be done by creating a custom plugin with a configuration file per endpoint. This type of library implements a specialized semantic rule engine. Easy to configure and to do as part of an API definition  

Web Application Firewall: If there is not a forefront WAF implemented on the incoming traffic, it will be required to implement a custom plugin that connects to a WAF instance.  

JWT session token validation: It is a plugin. It validates the session against the Login Service, which lifecycle manages the session.  

JWT session token authorization validation: It is a custom plugin. It validates the Token Claims – and scopes – against the User Access management component, validating the Routes and Application User Roles and the APIs they are entitled to use.  

Identity Aware plugin: This plugin will aggregate the invocations to the RBAC and the Session management capabilities.  

RBAC (Role-Based Access Control): This capability checks the roles or privileges granted to the User to use the API. It can be implemented in a custom plugin and calls an underlying service that brings the following information: Endpoint ->ApplicationRole->UserIdentity. The privilege of using an API endpoint is granted in the context of an application and uses the ‘Application’s User Roles provisioned to the User.  

ABAC (Attribute-Based Access Control): Attribute-Based Access Control. It is used to verify the content of the message. This capability provides security to incoming requests. It prevents the attack scenario when someone with a valid session token has enough skills to handcraft a payload and sends a handcrafted HTTP request to bypass the ‘application’s security. In this attack, data that is not ordinarily available to the User through the application can be leaked. See more about Kong API Gateway in the Technology Infrastructure section of this document.  

Identity Aware verifier: It adds intelligent policy-based verifications to API calls—for example, IP addresses (geolocation), client machine MAC addresses, application destination frequency, Time of access, etc.