Been wanting to simplify our architecture, I think DB-Less is a nice transition to play with if Kong is ready for that in the limelight 
.
I think it would be really cool to get to a point where I offload OAuth2.0 to a separate team internally at my co. that focuses on auth/IDP tools (ping federate, auth0 etc., key-cloak). Can write something to dump generated Kong creds over to that tool and let that team manage that infra and write the oauth token endpoints to point to that service for token gen and write a little tool to validate the tokens I see and kong consumer they belong to.
Big benefit here is DB outage or impact only impacts OAuth token gen and proxies protect with OAuth, whereas Kong when relying on DB has all kinda sync going on and admin api crud actions propagating everywhere, I would not mind taking all that away and going with a dead simple declarative config that gets built out via automation to add and remove resources customers need.
Following this guide:
Why is ACL plugin only partially supported? If I have consumers and their groups set if I set the context of a user and it has static ACL groups with them then the ACL plugin should be fine to validate that user and allow/reject txās right? No DB needed?
Description says:
Authentication plugins can only be used if the set of credentials is static and specified as part of the declarative configuration. Admin API endpoints to dynamically create, update, or delete credentials are not available in DB-less mode.
But this statement holds true for any and all plugins (admin api endpoints can edit anything anyways, everything has to be declared and stay static through the lifetime of it.) So is there no other limitation, seems full support so if I made a proxy with ACL + HS256 JWT auth both plugins would be able to function same as DB Kong no? JWT token leads to knowing who consumer is, consumer has groups, acl plugin sees groups and decides if reject or allow based on how configured.
Same goes for JWT Auth, why marked as only partially supported? A HS256 JWT(OR RSA pub/priv for that matter) can be declarative configured and when clients pass their token that token can be validated based on the key/secret declared in the config right?
Rate limiting we use local policy now so that should be compatible OOTB so thats good.
Are there any other gotchas I can think of? I figure export my DB data now using the CLI and try it out after I solve how I wanna do OAuth2.0 and it could be a reality?
Thinking about how to bring in changes, would it be worth rolling redeploying the pod itself with config changes if thats an option (think kubernetes/openshift deployments)? Would it be safe to do it on a polling of sorts where a kong reload gets done when the config pushed to the node with the fresh changes, or would be be impacting existing traffic calls during that reload of the new template. I imagine the rolling redeploy of pods where new pod comes up with new config and has its healthchecks/liveness probs validate out before taking traffic is the move vs reloading an actively taking traffic node risking impacting existing traffic.
As far as upgrade paths go in DB-less, generally that will just be slight refactorings of the format of the YAML declarative config correct (ex yall deprecate a field name I just go manually replace all to some other value for that field). Or will you have a tool that āupgradesā a declarative configs yaml file from one Kong to a newer version via CLI command? That way we do not have to worry about formatting it manually. Also new fields and such I would just write a yaml parse tool to add defaults/values into the config portions of the declarative if I needed to. Would be nice for new ādefaultā values the upgrade config cli command could populate all those in so if i wanted to edit that field I could find and replace the default conf to something else(if I was lazy and didnāt wanna write a parser lol.)