I have been using KIC in AKS for little over 3 months and soon will be deploying in baremetal Kubernetes cluster. I have the following requirement and wanted to know whether this is a scalable/feasible approach.
Backend service with paths /foo/user123A. /foo/user123B There can be 5 K such path, one per client.
Authentication using API KEY
One client cannot use their api key to access another clients resource , e.g user123A should not access /foo/user123B
Required Kong Configuration
Create 1 kong api auth plugin
Create 5k secret for api key
Create 5k secret for acl
Create 5k kong consumer and add acl/apikey secret pair ref to each
Create 5k kong acl plugin
Create 5k ingress with separate path/route and acl plugin in the annotation.
Lets assume we will have some kind of automation to manage these objects. With these many consumers , secrets and acl plugins will kong be able to handle this ?. Are there any benchmarks on how many consumers/secrets/plugins kong can handle . ( I saw this open issue too #2382 w.r.t the huge number of secrets causing kong startup issues )
Alternate approach is to use a central authority to get the role/actions the client is supposed to do, but this requires a lot of changes on the backend so would prefer to have this configured via Kong.
It’s generally an open question that depends on your container resource allocations, and we generally recommend load testing all configurations to get an initial sense of their performance characteristics. We have rough figures for memory usage, and expect that most resources consume a similar amount of memory (there aren’t any huge deviations in size between them). The Secrets issue is a bit of an oddball since they’re arbitrary-size standard resources, so while credential Secrets shouldn’t be large enough to cause an issue, other Secrets in the system are.
The new CombinedRoutes feature gate may be useful if you have many paths for the same Service on a single Ingress, though I think the config you’d need wouldn’t necessarily benefit from it.
The most common issues we see stem from upper limits on the ability of the DB-less configuration loader to load resources, since it needs to receive resources at once. Those can manifest as either failed configuration pushes or an unexpected spike in errors during or shortly after a push.
Let me know if this is the right way to do it. In order to set separate acl’s for each route I would need to create that many number of KongPlugin of type acl , equivalent number of secrets with KongCredType acl and equivalent number of Ingress with the respective acl plugin as konghq.com/plugins: annotation ?
Is there any other better way in configuring the acl without creating separate KongPlugin and Ingress routes ?
In your case since there’s a direct 1:1 relationship between the consumer and the route they’re allowed to access (only the single consumer can access routes for that consumer, nobody else), you may want to consider creating your own custom plugin that’s aware of the URL structure and can parse it to determine the user assigned to that URL and authorizing based on whether the URL user and actual user match.
The ACL plugin source is possibly a good start. You’d probably want to rip out the acls.lua, daos.lua, and migrations (the code used to manage the ACL credentials) and instead derive the group from the consumer username/custom ID and the allowlist from the URL. This dynamic approach should allow you to apply a single plugin instance to a route that handles all the consumer-specific URLs.