How I configured Kong Plugins…

Danuka Praneeth
5 min readAug 8, 2020

--

Let’s apply the plugins

This is a extension of my previous blog where I introduced the Kong API gateway and it’s main components. So if you are new to this wonderful product or the API gateway concepts, you can read it to brush up your knowledge before we go ahead and configure the plugins and advanced plugins on Kong API gateway.

Kong has an extensive collection of plugins which you can easily configure and apply to your APIs using few template and annotations. So here in this article I am discussing on how I configured a comprehensive API gateway in an OpenShift container platform with the Kong API gateway using it’s plugins and advanced plugins. I was using the Kong ingress controller version 0.9.0 and API gateway version 2.0.4 for this blog, which were the latest releases by the time I write this. I was using the db-less mode of the Kong which was perfectly fine for my internal gateway requirement. But if you are installing Kong as an external gateway, it is recommended to install the full version of Kong along with a database (eg: redis, postgress) to experience some additional features like analytics, management dashboards etc.

Kong API gateway as a the intermediary protection layer

Kong Plugins

Kong plugins enable us to implement policies for the applications running in Kubernetes or non-Kubernetes environment. Below is a basic introduction and sample templates to configure some of the most commonly used API gateway features via Kong plugins.

1) Authentication Plugins

1.1) JWT Plugin- Verify requests containing HS256 or RS256 signed JSON Web Tokens (as specified in RFC 7519). Each of your Consumers will have JWT credentials (public and secret keys) which must be used to sign their JWTs.

Steps to configure JWT plugin

1.2) OpenId Plugin- This plugin can be used to implement Kong as an OAuth 2.0 resource server and/or as an OpenID Connect relying party between the client and the upstream service.

Steps to configure OIDC plugin

I will discuss more on how to use this Kong OIDC plugin with an external authorization server to implement a more advanced authentication flow for your APIs with maximum security for any possible external attacks.

1.3) Key Auth Plugin- Once we apply this plugin, consumers should add their key either in a query string parameter or a header to authenticate their requests.

Steps to configure Key auth plugin

2) Security Plugins

2.1) IP Restriction Plugin- Restrict access to a service or a route by either whitelisting or blacklisting IP addresses. Single IPs, multiple IPs or ranges in CIDR notation like 10.10.10.0/24 can be used.

IP Restrict plugin template

2.2) Bot detection Plugin- Protects a service or a route from most common bots and has the capability of white-listing and blacklisting custom clients. Regular expressions will be checked against the User-Agent header for white-listing or blacklisting.

Bot detect plugin template

2.3) CORS Plugin- We can use this plugin to supports secure cross-origin requests and data transfers between servers.

CORS plugin template

3) Traffic Control Plugins

3.1) Rate limiting Plugin- Rate limit how many HTTP requests a consumer can make in a given period of seconds, minutes, hours, days, months or years.

Rate limiting plugin template

API trotting can be configured based on IP, consumer, credential, service, header. Advanced use-cases of rate limiting plugin with consumer policy along with the OIDC plugin will be discussed in a later article.

3.2) Request size limiting Plugin- Block incoming requests whose body is greater than a specific size in megabytes. For security reasons it is recommended enabling this plugin for any service you add to Kong to prevent a DOS (Denial of Service) attack.

Request size limiting plugin template

3.3) Request Validator Plugin- Validate requests before they reach their upstream Service. Supports request body validation, according to a schema.

Request validator plugin template

3.4) ACL Plugin- Restrict access to an API by whitelisting or blacklisting consumers using arbitrary ACL group names. This plugin requires an authentication plugin to have been already enabled on the API.

ACL plugin template

3.5) Canary release Plugin- Reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users. This plugin also enables roll back to your original upstream service, or shift all traffic to the new version.

Canary plugin template for 50% traffic redirection to upstream IP

3.6) Response Rate Limiting Plugin- This allows you to limit the number of requests a consumer can make based on a custom response header returned by the upstream service.

Response rate limiting plugin template to reduce the request limit based on header field ‘Data’

4) Analytics and Monitoring Plugin

4.1) Prometheus Plugin- Expose metrics related to Kong and proxied upstream services in Prometheus exposition format, which can be scraped by a Prometheus Server.

Kong plugin to enable Prometheus metrics

5) Transformation Plugin

5.1) Request Transfer Plugin- This has enhanced capabilities to match portions of incoming requests using regular expressions, save those matched strings into variables, and substitute those strings into transformed requests via flexible templates

Request transfer plugin sample template

5.2) Response Transfer Advanced Plugin- Transform the response sent by the upstream server on the fly on Kong, before returning the response to the client.

Response transfer advanced plugin sample template

6) Logging Plugin

6.1) Kafka Log Plugin- Publish request and response logs to a Kafka topic.

Kafka log plugin sample template

All the above Kong plugins can be configured either as KongPlugins or KongCluseterPlugins. The main difference is clusterplugins can accessible from any namespace of the cluster while kongplugins are specific to a single namespace.

Another important thing to note is that when you configure any plugin with the label “global: true”, such plugins will be applied for all the ingress endpoints by default. If the plugin doesn’t have this label, then you need to specifically configure the required plugin list inside your API endpoints.

How to apply the Plugins

Once you create the Kong plugins, the next step is to use them in your APIs. To expose your service via the Kong API gateway, you need to create an Ingress resource and add the required plugin list under the annotations.

You can also use the below command to apply the plugins for any existing ingress resource or service.

oc patch ingress ingress-ns -p '{"metadata":{"annotations":{"konghq.com/plugins":"plugin 1, plugin 2"}}}'oc patch service service-ns -p '{"metadata":{"annotations":{"konghq.com/plugins":"plugin 1, plugin 2"}}}'

You can read further on more advanced scenarios in my next article.

Thanks!

--

--

Danuka Praneeth

Senior Software Engineer | BSc (Hons) Engineering | CIMA | Autodidact | Knowledge-Seeker