Support multi‑namespace scoping for the Tekton controller

[lluisrubio]

Feature Request: Support multi‑namespace scoping for the Tekton controller

Problem statement

Tekton Pipelines currently supports two controller reconciliation modes:

1. Cluster‑wide — the controller watches all namespaces.
2. Single namespace — via:

   --namespace=<namespace>
   

This design follows the official multi‑tenancy documentation, which states that the supported model is running multiple controller instances, each restricted to a single namespace.

While this works for strict per‑namespace isolation, it does not support the following real‑world multitenancy scenarios:

• A single controller that should operate over a bounded list of namespaces (e.g., team-a, team-b, legacy-ci).
• Excluding certain namespaces where tenant‑specific controllers operate.
• Clusters where global Tekton must coexist with isolated tenant Tektons.
• RBAC models where cluster-wide permissions are not acceptable.
• Large clusters where watching all namespaces is inefficient or undesired.

Today, the Tekton controller can only be either global or restricted to exactly one namespace. There is no officially supported way to restrict the controller to multiple namespaces.

---

Related issue

This request is closely related to:

#4605

That issue highlights the need to support multiple Tekton installations in different namespaces for multi‑tenant clusters.

Our request is a lighter‑weight but highly aligned need:

Allow a single Tekton controller to watch a specific list of namespaces, instead of requiring multiple full Tekton installations.

---

Why this feature is needed

1. Namespace‑based tenancy is widely adopted

Many Kubernetes environments (OpenShift, GKE, IKS, on‑prem clusters, etc.) rely on namespaces as the unit of tenancy.

2. Global controllers are undesirable in multi‑tenant environments

A global controller:

• Watches tenants that it should not manage
• Generates RBAC 403 errors when access is intentionally restricted
• May reconcile resources belonging to other isolated Tekton installations
• Introduces operational noise in large clusters

3. Deploying 20–50 controller instances is operationally heavy

In large, multi‑tenant clusters, having one controller per namespace becomes:

• Expensive in terms of pods, memory, and CPU
• Hard to maintain via GitOps
• Error‑prone across lifecycle events and upgrades

4. RBAC alone is insufficient

Even if RBAC denies access, a cluster‑wide controller will still attempt to watch all namespaces, generating:

• Thousands of Forbidden messages
• Unnecessary load on the API server
• Noisy logs and degraded observability

5. A list-based controller scope is a natural middle‑ground

Supporting multi‑namespace scoping avoids:

• Extreme A: Single global controller (too permissive)
• Extreme B: One controller per namespace (too costly)

---

Proposed feature

Option A — Add a multi‑namespace flag

--namespaces=team-a,team-b,legacy-ci

Option B — Add namespace exclusion

--exclude-namespaces=kube-system,kube-public,tekton-tenant-a

Option C — Add label selector

--namespace-selector=tekton.dev/managed=true

Benefits

• Enables practical multi‑tenant deployments
• Reduces operational overhead
• Improves security boundaries using RBAC least privilege
• Eliminates cluster‑wide watch overhead
• Prevents accidental reconciliation in isolated tenant namespaces
• Backward compatible

---

Non-goals

• Per‑namespace webhook instances
• Namespace-scoped webhook validation
• Per‑namespace resolvers
• Per‑namespace eventing

(These remain cluster‑scoped.)

---

Willingness to contribute

We are willing to:

• Support design discussions
• Provide PoCs
• Test across multiple Kubernetes distributions
• Draft a Tekton Enhancement Proposal (TEP)

---