Common rate limiting for all consumers


#1

Hello!

We’re using Kong as an API GW and we’re supposed to have rate limiting for protecting APIs from too many requests, for instance brute force attacks. It seems that with Kong’s Rate Limiting plugin, “limit_by” value can only be “consumer”, “credential” or “IP”. This doesn’t really fit to our needs, as it seems impossible to configure the rate limiting as ‘global’, common for all consumers (if for instance we configure the rate limit to be X requests / sec, each client can make X requests per second, we would want to have the configured rate limit to be X requests / sec for all consumers).

Have we misunderstood something, is it possible to configure the rate limiting for all consumers?

Thanks in advance,
Markku


#2

A truly global rate limit would present a probably undesirable attack vector - a single nefarious actor, or even just a user making a mistake, could take down your service for ALL of your users.

What prevents you from using per-consumer, per-credential, or per-IP rate limiting to protect your backend service and help ensure reliable service for all your users?


Rate limiting behaviour
#3

The requirement for having a truly global rate limiting, comes from our API development teams. Some of the APIs have performance limits and exceeding the limits is said to cause troubles with capital t. Fixing the performance issues is unfortunately totally out of our hands. That’s why the idea was to protect the APIs by setting a global rate limit.


#4

Pretty sure the plugin works like so:

Enable it globally, set a per second rate limit, put the limit buy consumer as the option.

Plugin will limit all proxies by consumer individually by default, and fall back to IP if no Kong native auth plugin on the proxy is found.

For instance we set a 500 TPS rate limit globally to limit by consumers, we expect no single proxy to go over 500 TPS from a single authorized consumer as just a safe guard. Of course sometimes we set local proxy rate limitings much lower and tied to a specific consumer id if needed.


#5

Thanks Cooper, for your answer on the other thread.

I just submitted a pull request on github implementing this.


julienlau
feat(rate-limiting) global rate-limiting to protect back-end
by julienlau on 04:19PM - 27 Nov 18 UTC
1 commits changed 2 files with 4 additions and 2 deletions.
You do not need to recompile anything to use it.
Overwrite the lua scripts from your existing rate-limiting plugin and restart kong.

Example:
git clone blabla
scp kong/plugins/rate-limiting/handler.lua scp kong/plugins/rate-limiting/schema.lua root@server-kong:/usr/local/share/lua/5.1/kong/plugins/rate-limiting/

It does not bother me that one consumer could block the others by reaching the global limit.
In fact, I am currently implementing this with 2 layers:

  • one rate-limiting at a global level, in which I can set limits according to hard limits of the back-end servers and protect the platform from being flooded.
  • one rate-limiting per consumer, which is independent from hardware/tech stack considerations and more linked to the contract that I have with them.
    But in any case, I do not want to the math: I have N concurent consumers and platform capacity is X q/s so, I only have to put X/N as a rate limit to all consumers.

In my case Availability is more important than Latency and the usage of consumers is not well known… yet

If one consumer is flooding the service thanks to a high q/s limit per consumer, he will soon be blocked in terms of q/m, q/h, q/d so that the platform will be able to answer without completely breaking due to an overwhelming backlog of requests to DB.