Trying Kong Gateway on Kubernetes

March 12, 2022

I recently had to get my hands on Kong Gateway to check if it would be capable of fitting one use case I had in mind.

Basically I wanted to use it to rate-limit requests to a service, but in a way that anyone holding an api-key would have bigger rate-limits than anyone without an api-key.

For this I decided to use the key-auth plugin in conjunction with the rate-limiting plugin.

Installing was easy enough. Since I was using Minikube for this PoC, I just had to do what is described in https://docs.konghq.com/kubernetes-ingress-controller/2.2.x/deployment/minikube/

I’ve also setup an echo-server for testing as described in https://docs.konghq.com/kubernetes-ingress-controller/2.2.x/guides/getting-started/, and configured a basic rate-limit. All very easy.

However, when trying to setup the key-auth plugin, their docs weren’t clear enough on how to integrate it with Kubernetes secrets to store the api-keys.

Using Kubernetes secrets for the api-keys

To store the api-keys in Kubernetes secrets and make Kong use them, you first have to create the secret, obvisouly. This can be done with the following command:

key=$(openssl rand -hex 32)

# You can change the name of the secret to something else
kubectl create secret generic consumer-apikey --from-literal=kongCredType=key-auth --from-literal=key=$key

Then you need to create a KongConsumer object. Since we are working with Kong in DB-less mode, everything needs to be done declaratively.

Here is the file which is configured to use the secret to get the api-key from:

apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: consumer
  annotations:
    kubernetes.io/ingress.class: kong
username: consumer
credentials:
  - consumer-apikey  # This is the name of the secret we created earlier

Apart from this, everything is clear in their docs. Defining the plugin and configuring some route/service to use it are missing from my explanation, but are needed for the whole thing to work.

What about my use case?

If you are curious about whether I succeeded in the PoC, the answer is no.

Kong’s open-source plugins were not able to perform the rate-limiting I wanted, because the rate-limiting plugin does not support setting different rate-limits for different consumers.

To understand this, first you need to understand how I configured the plugins.

Basically I had to use the config.anonymous option of the key-auth plugin to make it allow anonymous requests.

However, to do this you need to create a Consumer which will be associated with all anonymous requests.

Then I hit 2 limitations of the open-source plugins:

The rate-limiting plugin does not support setting different rate-limits for different consumers.
I was unable to configure an integration between them were the rate-limiting plugin used the Origin IP of requests for the case of anonymous requests, instead of using a consumer.

There is an enterprise plugin, rate-limiting-advanced, which is able to do item 1. But I’m not sure item 2 is possible somehow with Kong.