Configuring Kong for multiple tiers of users

1

Hi!

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:

  1. frontend users (we have a website that consumes our own api. These users may be rate-limited on IP basis)
  2. free users (upon requesting a key, these users can access our api, but rate-limited and CORS limited)
  3. all-you-can-eat (no rate-limit, or a very high one. No CORS)
  4. 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: Enabling cors plugin on consumer level · Issue #5736 · Kong/kong · GitHub). 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?

2

I’ve figured it out. The issue was with the proxy-cache plugin I installed, delaying configurations to kick in.

For those in a similar situation as me, I’ve opted for option three in my question: proxying Kong to itself. It seems to work nicely.

Not sure if proxying to itself is a good practice though, if anyone has any insights in this I would love to hear it.

3

Another update; although my configuration works, it is somewhat limited. A consumer may belong to multiple groups, which probably results in a X-Consumer-Groups header value of e.g. ‘foo,bar’. The headers attribute only checks for full matches, which means that a route configured for consumers in the foo group won’t be matched to consumers that belong to both the ‘foo’ and the ‘bar’ group.

I can kinda work around this for now, but it makes it kinda a dodgy solution probably resulting in some consumers in the future not being able to reach certain routes, because we forgot about the caveat of this hack and added someone to an extra group.