Remove `clusterinterceptors` and `clustertriggerbindings` from `aggregate-to-edit` ClusterRole

[vdemeester]

Summary

The tekton-triggers-aggregate-edit ClusterRole (config/clusterrole-aggregate-edit.yaml) includes cluster-scoped resources (clusterinterceptors, clustertriggerbindings) alongside namespace-scoped resources. Including cluster-scoped resources in a role aggregated into the user-facing edit ClusterRole is permitted by Kubernetes RBAC, but is broader than necessary and not aligned with least-privilege for Tekton's threat model.

While Kubernetes correctly prevents namespace RoleBindings from granting access to cluster-scoped resources, including them in aggregate-to-edit means that any user with a ClusterRoleBinding to edit (e.g. in multi-tenant setups) gets full CRUD access to all ClusterInterceptors and ClusterTriggerBindings. These are shared resources that affect all tenants.

Current State

config/clusterrole-aggregate-edit.yaml:

rules:
- apiGroups:
  - triggers.tekton.dev
  resources:
  - clustertriggerbindings    # cluster-scoped — should not be here
  - clusterinterceptors       # cluster-scoped — should not be here
  - eventlisteners            # namespace-scoped — OK
  - interceptors              # namespace-scoped — OK
  - triggers                  # namespace-scoped — OK
  - triggerbindings           # namespace-scoped — OK
  - triggertemplates          # namespace-scoped — OK
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch

Proposed Fix

Remove clusterinterceptors and clustertriggerbindings from tekton-triggers-aggregate-edit. Read-only access is already preserved via aggregate-to-view.

Users who need to manage cluster-scoped Triggers resources should be granted a dedicated ClusterRole explicitly.

Breaking Change

Users who currently rely on a ClusterRoleBinding to the edit ClusterRole for managing clusterinterceptors or clustertriggerbindings will lose that access. They will need an explicit ClusterRoleBinding to a role that grants those permissions.

This does not affect users with namespace-scoped RoleBindings (they never had access to these cluster-scoped resources regardless).