-
Notifications
You must be signed in to change notification settings - Fork 1
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
How to configure KongPluginBindings
to be global
#7
Comments
I believe that making the binding explicitly global would be beneficial. So something along these lines should work: diff --git a/api/configuration/v1alpha1/kongpluginbinding_types.go b/api/configuration/v1alpha1/kongpluginbinding_types.go
index 2c9b3dd..33c02ec 100644
--- a/api/configuration/v1alpha1/kongpluginbinding_types.go
+++ b/api/configuration/v1alpha1/kongpluginbinding_types.go
@@ -60,6 +60,14 @@ func (c *KongPluginBinding) SetConditions(conditions []metav1.Condition) {
// KongPluginBindingSpec defines specification of a KongPluginBinding.
type KongPluginBindingSpec struct {
+ // Global indicates if the plugin is global or not.
+ // If set to true, the plugin will be applied to all entities in the Kong
+ // cluster. If set to false, the plugin will be applied only to the entities
+ // specified in the references.
+ //
+ // +kubebuilder:default:=false
+ Global bool `json:"global"`
+
// PluginReference is a reference to the KongPlugin or KongClusterPlugin resource. It is required
PluginReference PluginRef `json:"pluginRef"` WDYT? The only thing that I believe we can't (easily) do now is to block more than 1 global plugin on admission. Neither CEL on a CRD nor Given this I think the only option to enforce this would be to use the admission webhook. |
Re-opening as the addition of a global field in the We may need to introduce a new cluster-wide CRD named |
Meeting with @mlavacca today we've decided to not implement this ATM as this would have more implications on crossing the namespace boundaries. Let's postpone this until we have product demand for this. |
Problem Statement
#1 introduced the new
KongPluginBinding
CRD to allow users to bind plugins to specific kong resources. The fieldPluginRef
has been added to the.spec
field, and such a field contains the Kind along with the plugin Name. Such a kind field is meant to be used to either refer to KongPlugin or KongClusterPlugin.Since https://docs.konghq.com/gateway/latest/key-concepts/plugins/#precedence defines the precedence for each entity that can have plugins attached, we could think of just using the
KongPluginBinding
resource to determine the scope of a plugin. In konnect, no entity attached to a plugin means "global" and so we could do.A separate effort is about using the
pluginBinding
to configure regular Kubernetes resources in a Gateway, but that's a separate effort described in #8.Proposed Solution
spec.pluginRef.kind
field.Additional Information
Acceptance Criteria
The text was updated successfully, but these errors were encountered: