Skip to content
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

Open
1 task
mlavacca opened this issue Jul 25, 2024 · 3 comments · Fixed by #11
Open
1 task

How to configure KongPluginBindings to be global #7

mlavacca opened this issue Jul 25, 2024 · 3 comments · Fixed by #11

Comments

@mlavacca
Copy link
Member

mlavacca commented Jul 25, 2024

Problem Statement

#1 introduced the new KongPluginBinding CRD to allow users to bind plugins to specific kong resources. The field PluginRef 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

  • Get rid of the spec.pluginRef.kind field.
  • Allow kong references to be empty
  • If that's the case, the plugin is global

Additional Information

Acceptance Criteria

  • As a user, I can easily define global plugins in Konnect
@pmalek
Copy link
Member

pmalek commented Jul 30, 2024

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 ValidatingAdmissionPolicy allow inspecting other objects during admission.

Given this I think the only option to enforce this would be to use the admission webhook.

@mlavacca
Copy link
Member Author

mlavacca commented Aug 9, 2024

Re-opening as the addition of a global field in the KongPluginBinding breaks the namespace isolation of a cluster: a namespaces resource shouldn't be able to affect resources belonging to different namespaces.

We may need to introduce a new cluster-wide CRD named KongClusterPluginBinding with no targets. Such a CRD will allow to set a KongClusterPlugin as global, in the context of both KIC and Konnect.

@pmalek
Copy link
Member

pmalek commented Aug 13, 2024

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.

@mlavacca mlavacca removed their assignment Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants