Global Plugins - Understanding the current approach


I was playing with the new global plugin support and at this moment it’s not possible to configure a “global” consumer for plugins like rate-limiting, request-size-limiting, etc.

What I did to solve this, I modified the code to support this. You could check the snippet here

But having a “global” with consumer doesn’t fit for me. Because if we read the definition of the global plugin from the documentation said “A plugin which is not associated to any Service, Route or Consumer (or API, if you are using an older version of Kong) is considered “global”, and will be run on every request.” If we take that statement having a label called global: “true” it’s not necessary because could be inferred from a CRD like this

I think that we need to be closer to the actual documentation. I don’t know what is the best option. I’ve some ideas like always create a global plugin (if its possible) when we create the CRD and if the user doesn’t want it, he needs to be explicit like global: “false” I know that looks similar to the actual behavior but it’s closer to the actual definition. And other option could have a new CRD called KongGlobalPlugin that will work in global and consumer level and the services, route, and consumer wil be handled by the KongPlugin, and another option maybe is resolve this in the code directly only with one CRD and adding subresource to show to the user if the KongPlugin is running in global mode, adding properties like plugin name, some config, and status but that only will work on 1.11.

I opened this topic to start a discussion and also to understand the approach that you guys are looking for.

Kind Regards!

Hello @bugbuilder,

Thank you for starting this discussion.

Introducing another CRD for this problem sounds like a bigger hammer than necessary.

I’ve been thinking around how to improve the consumer-level plugin configuration management via k8s.
Annotation seems to be another solution that could work here.
Basically, whenever an annotation, let’s say : "consumer_CRD_name" (value part can be a CSV) is present, then the plugin will be configured to be executed for that specific consumer only.

Using this approach, putting the above annotation on different resource will have different effect:

  • KongPlugin: the plugin will be configured for the specific consumer(s) whenever it is referenced in Ingress or Service resources.
  • Ingress: all plugins for will be configured for a route and consumer(s)
  • Service: all plugin will be configured for a service and consumer(s)

To configure a plugin for a specific consumer(s), there can exist (yet) another annotation which can be applied to KongPlugin Custom resource.

It would be nice to not have an annotation explosion

The other route will be to use labels for consumer-level configuration with KongPlugins (making it searchable)

Could you share your use case where you’re using a consumer specific plugin (or a consumer and route/service specific plugin)?
I’m trying to understand use cases for consumer-level plugins in k8s environment right now and would move to implementation once we’ve good number of use-cases.

Hi @hbagdi,

Thank you for you feedback.

Let me talk with me colleagues this week and then I’ll post you some use cases.