Global Plugins - Support "exclude" of services/routes

[liorsamuni]

Currently, Kong has the option of enabling a plugin per service/consumer, enabling it globally etc.

What is missing is the ability to enable a plugin globally, but to exclude it from certain services/paths.

E.g. when working with declarative configuration, i can see kong support the following:

_format_version: "1.1"
services:
- name: my-service
  url: https://example.com
  plugins:
  - name: key-auth
  excluded-plugins:
  - syslog

plugins:
   - name: syslog

(other valid option is to have a new attribute added to the global plugin definition, with excluded services/routes capability)

[Tieske]

for reference, see distinction between disabled and unavailable here: #1279 (comment). Similar approach could be used here as well probably.

[liorsamuni]

@Tieske i do not think the attached ticket is helpful nor addressing the need

The goal is to have Kong built in support for excluding global plugins from specific services.

[liorsamuni]

@Tieske any update on this one?

[Tieske]

making it bhave this way only for global plugins doesn't make sense. It would also be useful to have a plugin enbaled on a service (with say 10 routes), and then disable it on 1 of those routes. eg. 1 enable, 1 exception == 2 config items, as opposed to enabling it on 9 routes == 9 config items.

[liorsamuni]

@Tieske right.
I just wanted to point out the need
Of course it should be configrable and generic across kong's conif items

[kcammanabrolu]

This I see is very limiting.... We will have many situations where we would like to configure a plugin on a service or globally but exclude it for certain exceptions. For example we want to use OAuth2 Introspection plugin on all of our 150 routes except for 2 of them. W/o this feature, we are forced to configure plugin on all the 148 endpoints by hand. Is there a way to increase the priority of this request ?? Please suggest

[hbagdi]

decK can help here in making it easy to manage the configuration:
https://deck.yolo42.com/guides/distributed-configuration.html
https://deck.yolo42.com/guides/deduplicate-plugin-configuration.html

[xulis]

+1

[clhlc]

+1

[jasine]

+1

[alexbud]

+1

[gzollman]

+1

[ucarbehlul]

+1

[pbkh-bunthai]

+1

[motiisr]

+1

[marcusschmidt]

+1

[pbkh-bunthai]

#5233 (comment)
liorsamuni is right
@bungle please reconsider it

[FaustPipeDream]

+1.it's a useful feature.

[hbagdi]

Doing this inside the Gateway could be a little more challenging. There are hacks possible like using tags to exclude a global plugin for a service/route but that would be a new pattern - tags are not used routing logic anywhere.

The other way to solve this problem is my making it a configuration problem and moving the problem into decK: Kong/deck#339. The solution in decK could be a bit more generic where you could selectively include/exclude plugins.

[Tieske]

currently there is the enabled flag, which is true by default. We could add another flag, disabled for example (false by default), that would disable a plugin.

enabled	disabled	result
true	false	(these are defaults), plugin is loaded an executed
true	true	plugin is loaded, but not executed, also lower precedence versions (like global ones) are NOT executed
false	false	plugin is not loaded. Kong behaves as if it does not exist, will fallback on lower precedence ones
false	true	plugin is not loaded. Kong behaves as if it does not exist, will fallback on lower precedence ones

This is what I meant with the older comment above.

But how to deal with plugin schema/config validation? Skip validation all together, if disabled is true? or still require a valid config table.

[nwsparks]

This seems to have stagnated since being converted from an issue. It would be nice to get more discussion around this. We have 38 services in kong and have to apply the same plugin configuration to 36 of them resulting in mountains of duplication and a config that is much larger than necessary. If you ever then need to dump the config back out to evaluate it's pretty difficult to do so.

[skalinkin]

+1
Maybe also consider to make service, route, consumer support multiple entries

plugins:
- name: openid-connect
  service: 
   - service1
   - service2

[altais]

+1

[hbagdi]

Question for all:
Would executing the plugin based on a "match" logic that is different from routes/services help?

Today, one can configure a global plugin, or a plugin on a resource (route, service, consumer).
What if one could trigger the execution of a plugin based on "match" (or negative match) of HTTP request metadata.

The "match" would happen in addition to plugins configured on resources.

[niteshraika]

What is the status of this feature request of the current discussion? If anyone has any idea!

[HomiG]

Such a basic functionality is missing since 2019. Is there any progress on the issue?

[jcfvalente]

Any update? This would be a really useful feature so that we don't have to duplicate plugin configuration.

[naolaregaqena]

Any update on this feature, it is much needed feature since 2019

[hanshuebner]

What really seems to be desired is a way to have more fine-grained control over how plugins are attached. Currently, Kong gateway only provides Global, Service, Route and Consumer as possible scopes, and that hierarchy is insufficient for many use cases. The standard answer, however, has been to suggest the use of external tooling to generate the desired configuration - i.e. generate an instance of the desired plugin at each service/route/consumer that needs to have it.

That said, we do see the need to improve in this area, but we have not reached consensus that global attachment + exclusions would be the best way going forward. Another idea that has been circulated is to allow plugins to be created in a "floating" manner, i.e. without an implicit attachment point, and then use a mechanism like labels to attach them to a route, service or consumer.

Nothing in this area is going to make it into Kong quickly (i.e. it will take more months), so if you need to use the same plugin in many places, you'll need to instantiate it in all of those places.

[garciasdos]

Is there any update on this feature, or are there any plans to do something related to improving plugin attachment control?

[hanshuebner]

There are no new developments or plans in this area.