Plugin config defaults/merging

[dcarley]

Is there an existing issue for this?

• [X] I have searched the existing issues

Problem Statement

We keep coming across scenarios where the merging of plugin configs would be really useful when a team managing Kong provides a default configuration of a plugin and other teams using Kong want to override certain aspects of the plugin configuration. There are two variations of this, which could be separate feature requests, but I'm combining them because it's possible that they could be solved by the same implementation.

Infrastructure defaults

For example rate-limiting is configured globally with a default threshold and central Redis instance. Other teams want to override the threshold without duplicating the connection details (hostname, authentication, timeouts, policy, etc).

Same plugin for multiple purposes

For example response-transformer is configured globally to set security headers like HSTS. Other teams also want to use the plugin to set Cache-Control headers without omitting or duplicating the global configuration.

Proposed Solution

Infrastructure defaults

So far we've worked around this by forking some plugins to read defaults from environment variables but this approach doesn't scale very well. There was a previous feature request against KIC to read individual parameters from Secret resources (https://github.com/Kong/kubernetes-ingress-controller/issues/2098) but it was closed in favour of the new secrets management feature. Would it be appropriate to allow all parameters to be referenceable?

Same plugin for multiple purposes

So far we've worked around this by moving global header manipulation into pre-function/post-function plugins or combining common configurations into something like a "profile", but neither are very user friendly or scale very well. I think this would require actual deep merging of configurations by KIC that would allow config maps to be set or unset, similar to Helm values. How would you feel about that?

Additional information

No response

Acceptance Criteria

No response

[scseanchow]

Hi @dcarley thank you for this suggestion. After talking internally with the team, we believe this conversation may solve some of your use cases. What are you thoughts?

[dcarley]

@scseanchow Is that the right link? It doesn't look to be related to this.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[scseanchow]

@dcarley sorry, I linked the wrong PR 😓, correct link is here.

There are a few discussions regarding management of plugins such as this issue as well which may interest you. I will be working with the team to prioritize some of these and come out with a release that covers this use case.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dcarley]

@scseanchow Thanks. That would certainly solve the "Infrastructure defaults" aspect - I'll follow along those issues and KEP0010. It wouldn't solve the "Same plugin for multiple purposes" aspect. Should I keep a separate issue for that?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.