-
Notifications
You must be signed in to change notification settings - Fork 480
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable fine-grained cluster resource scoping for validations.kong.konghq.com
webhook
#1103
Comments
validations.kong.konghq.com
webhookvalidations.kong.konghq.com
webhook
thanks @msmost for raising the issue. We are facing the same problem. We currently have 3 kong KIC deployed (different teams, use cases, security requirements and lifecycles). Some indeed have different custom plugins. I actually just went ahead and reproduced exactly your custom plugin You can see in the screenshot below (GCP logs) that the validation webhooks (one for each kong) return different status codes
those responses code are obtained by running the last command of your guide, i.e. echo '
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: my-custom-plugin
namespace: kong-green
config:
header_value: "my first plugin"
plugin: myheader
' | kubectl -n kong-green apply -f - but
even though the validation webhook of Looking at your helm chart, there's indeed a But that wouldn't work for us as we don't control what workload is running in which namespace, and most of the time, our 3 kong instances will route traffic to workloads in the same namespace. The most practical solution seems to continue leveraging the annotation annotations:
kubernetes.io/ingress.class: kong-green just like for the rest of the resources. Thank you for your help. |
Hi @joran-fonjallaz and @msmost, As I read this issue I believe adding |
@pmalek - yep! Thinking that will solve the issue. |
Problem Statement
We deploy the kong helm chart twice into the same cluster:
We also leverage custom plugins, and deploy them as (global)
kongclusterplugins
.The validations.kong.konghq.com webhook rules are currently matching on kongclusterplugins.
Consider a scenario where we have a global custom plugin v1 deployed to research and test. Then we decide we want to create v2, which has a slightly different schema. If we try to deploy v2, the webhook deployed to the test environment does not yet know about the new version of the plugin and fails admission to the cluster. The chart currently support configuration of a
namespaceSelector
but this only applies to namespaced objects, andkongclusterplugins
are not namespaced.Solution proposal
One approach would be to update the
objectSelector
to include amatchLabels
selector (configurable withvalues
), so that labels could be used to select individual objects that are desired to be excluded from validation.The text was updated successfully, but these errors were encountered: