ClusterRoleBinding name collision between same-named Authorino instances in different namespaces

[KevFan]

Describe the bug

When two cluster scoped Authorino instances share the same CR name (e.g. both named authorino) but live in different namespaces, they collide on a single cluster-scoped ClusterRoleBinding and overwrite each other's permissions.

The ClusterRoleBinding name for Authorino's Kubernetes TokenReview/SubjectAccessReview role is derived from the CR name only:

<crName>-authorino-k8s-auth

Because ClusterRoleBindings are cluster-scoped and the name does not include the namespace, two instances both named authorino resolve to the same binding, authorino-authorino-k8s-auth. The operator reconciles this binding with Server-Side Apply, setting subjects to just its own ServiceAccount.
Since subjects is an atomic list under SSA, each reconciliation replaces the field rather than merging — so whichever instance reconciles last wins, and the other instance's ServiceAccount is evicted from the binding.

The affected instance then fails Kubernetes token reviews, e.g.:

  tokenreviews.authentication.k8s.io is forbidden:
    User "system:serviceaccount:kuadrant-system:authorino-authorino"
    cannot create resource "tokenreviews" in API group
    "authentication.k8s.io" at the cluster scope

This is a follow-up to #291 / PR #292. PR #292 made binding names instance-specific by CR name, which fixes instances with different names, but it does not disambiguate by namespace — so same-named instances in different namespaces still collide.

To Reproduce

Steps to reproduce the behavior:

1. Deploy a cluster-wide Authorino instance named authorino in namespace ns-a.
2. Deploy a second cluster-wide Authorino instance, also named authorino, in namespace ns-b.
3. Inspect the shared ClusterRoleBinding:

oc get clusterrolebinding authorino-authorino-k8s-auth -o jsonpath='{.subjects[0].namespace}'

3. It reports only one namespace — whichever instance reconciled last.
4. Trigger a re-reconcile of the other instance (e.g. annotate it), then confirm the first instance's ServiceAccount can no longer create
   tokenreviews:

 oc auth can-i create tokenreviews.authentication.k8s.io \
  --as=system:serviceaccount:ns-a:authorino-authorino
# -> no

Expected behavior

Each Authorino instance should get its own ClusterRoleBinding that is not affected by any other instance, regardless of CR name or namespace. Both instances should retain the ability to create tokenreviews/subjectaccessreviews, and inference/auth requests routed through either instance should succeed.

Screenshots

N/A

Additional context

• Discovered in an RHOAI 3.4 + Red Hat Connectivity Link (RHCL) LLM-D setup, where Kuadrant creates an Authorino instance named authorino in kuadrant-system alongside a pre-existing authorino instance in another namespace. All authenticated inference requests to the gateway returned HTTP
  401, and the associated AuthPolicy reported Enforced: False.
• The authorino-manager-k8s-auth-role ClusterRole itself is correct; only the binding's subjects field is affected.
• Proposed fix: include the namespace in the cluster-scoped binding name (e.g. <namespace>-<crName>-authorino-k8s-auth) so bindings are globally
  unique per instance, plus a best-effort cleanup of the legacy <crName>-<suffix> names on upgrade.
• Workaround: manually create a uniquely-named ClusterRoleBinding for the affected instance:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kuadrant-system-authorino-k8s-auth-manual
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: authorino-manager-k8s-auth-role
subjects:
- kind: ServiceAccount
  name: authorino-authorino
  namespace: kuadrant-system

[KevFan]

\cc @crstrn13 for awareness