At our upstream server we have a fairly simple API with a couple of endpoints, of all which could fit under one service and one route. However, we’re expecting a lot of users and I have to distinguish them in four categories:
- frontend users (we have a website that consumes our own api. These users may be rate-limited on IP basis)
- free users (upon requesting a key, these users can access our api, but rate-limited and CORS limited)
- all-you-can-eat (no rate-limit, or a very high one. No CORS)
- enterprise (some custom requests)
How to set this up in Kong is bugging me for a while now. Considered options are:
- Make different services and routes to split the frontend users (that are not matched to a consumer) and api users. This would solve splitting group 1 from the rest.
The others are harder:
- A working option is adding a rate-limit plugin for every user, and creating a custom CORS plugin that can be installed per user (the current one can’t: https://github.com/Kong/kong/issues/5736). This option is very hard to maintain, because it would mean maintaining all the plugins for every user instead of just a route or service
- Installing plugins per consumer group would be awesome, which I hope gets released soon but the latest news I found here dates back to 2018: Support for attaching API plugins to groups
- I’ve considered creating a first service that proxies to a second service in the same Kong gateway, including the x-consumer-groups that can be added to requests in the upstream, and then making routes in that second service that have to match the right consumer group header. Somehow this doesn’t work, and i’m not sure if it is really a good idea to redirect all traffic through Kong twice…
So long story short, I’m very much looking forward to installing plugins on groups, but for now it seems I’m stuck with option one. Is it such a weird edge-case scenario i’m in? Or is there a solution i am missing?