Dynamic provisioning of consumers

[emwalker]

I've looked through the docs, through the Kong and go-pdk code and through several forums, and I haven't found anything on the question of the dynamic provisioning of consumers. If there is a previous discussion thread on this topic that will be helpful, please point me to it.

I'm wondering what the recommended approach is for a custom auth Go plugin in the case where a bearer token is recognized by an internal service outside of Kong, and information about the user of the bearer token has been obtained, but there is no associated Kong consumer for that user. It would be convenient to provision a Kong consumer dynamically.

I'm thinking one of these might apply in this case:

1. There's already a way to do this, and you just have to call into a certain go-pdk function to provision the consumer from the Go plugin
2. go-pdk doesn't have a hook for provisioning consumers on the fly, but you can accomplish this by using lower-level function calls
3. It's a viable approach to POST to the admin API's /consumers endpoint from the plugin to create a new consumer
4. Kong doesn't recommend dynamically provisioning consumers in this case; you should only provision them ahead of time, outside of a Kong plugin, using the admin API

Any help is appreciated.

[kikito]

Hello @emwalker, the Go PDK doesn't currently have a way to create entities or manipulate the database. Nothing special prevents us from providing that feature in Go, it's just that it is not there yet.

I see two ways to fix your problem:

• Writing the plugin in Lua instead of Go. Lua is always ahead in terms of features, being the language that Kong itself is written in.
• Sending a pull request that adds the missing bindings to https://github.com/Kong/go-pdk

[emwalker]

Thank you, @kikito. Am I correct in understanding that adding consumers dynamically in the middle of a normal request path would be an ok thing to do, e.g., in a Lua plugin?

[kikito]

Yes, adding consumers dynamically is ok. You will have to do some due diligence though - for example, take into account that ill-intentioned actors might try to use that feature to bring down the service, if they are able to create many consumers quickly with a loop.

[emwalker]

Also, what do you think about option (3) above, POSTing to the admin API from the Go plugin? Will that be ok, or will there be a race of some kind?