Namespace scoped Interceptor

[khrm]

Feature request

Today, interceptors can be configured directly in the EventListener definition, which allows Teams to have their own/custom interceptors configured and managed in their namespace without the need of having any specific permissions (only admin permissions in the namespace).

With TEP-0026: Pluggable Interceptors this will go away (as per Any current Interceptor configuration is still usable (until beta) in the new model without requiring any manual changes on part of the end-user. As part of the beta, we can deprecate the old syntax.) and therefore require elevated privileges to create/register their custom interceptors.

In OpenShift Container Platform 4 - Clusters hosting multiple tenants, this will cause massive disruptions as specific tenants will have difficulties registering/creating custom interceptors depending on the permissions given or else they will be shared with different tenants which are also not acceptable.

It's therefore requested to either re-consider the deprecation of the current functionality where the interceptors can be configured directly in EventListener or else provide an approach with the new implementation that allows to use it on tenant level, where the resources are completely isolated on namespace level.

The key goal should be that the namespace admin can create and manage its interceptors without requiring elevated permissions and that the resources are restricted and thus not visible to other tenants and therefore namespaces.

Request and Written by: Simon Reber (Red Hat)

[dibyom]

Yup I don't think we can remove the current webhook interceptors until we also have namespace interceptor support

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.