Support for Strongly Isolated / Namespace-Scoped ToolHive Operator Installations

Background

ToolHive Operator is currently installed cluster-wide and configured to watch multiple namespaces (defined via operator.rbac.allowedNamespaces).
This approach works well for most environments that don’t require strict isolation, but some deployment scenarios — particularly those in highly regulated or multi-tenant setups — call for strong isolation between namespaces.

In such cases, users would like to install one ToolHive Operator per namespace within the same cluster, ensuring that:

• Each Operator instance has access only to resources within its own namespace.
• RBAC permissions are scoped to that namespace (using Role/RoleBinding instead of ClusterRole/ClusterRoleBinding).
• There are no shared management surfaces or privileges across namespaces.

This model can be justified in environments where isolation boundaries must be enforced at the namespace level, rather than relying solely on cluster-wide RBAC policies.

Current Behavior

• Even when operator.rbac.scope=namespace is set, the Helm chart still installs a ClusterRole (toolhive-operator-manager-role).

• Deploying ToolHive as a Helm subchart multiple times (e.g., once per namespace) results in an error because the ClusterRole name already exists cluster-wide:

  Error: INSTALLATION FAILED: Unable to continue with install:
  ClusterRole "toolhive-operator-manager-role" in namespace "" exists
  and cannot be imported into the current release: invalid ownership metadata;
  

• Some users have worked around this by locally changing the ClusterRole to a namespaced Role and adding a corresponding RoleBinding. While this works for isolated testing, it diverges from the upstream configuration and may introduce maintenance challenges.

Next Steps

We should discuss whether to officially support namespace-scoped ToolHive Operator installations, acknowledging the added complexity this introduces — notably CRD version uniformity issues. Since all Operator instances share the same CRDs, version management and upgrades become significantly more complicated.

The most valid justification for this approach is in environments demanding strong isolation between namespaces.
However, as is often debated in Kubernetes circles:

“If you need that much isolation, why not use multiple clusters?”

Still, providing an option for namespace-scoped deployments could benefit teams willing to accept the added complexity in exchange for isolation — without the overhead of managing multiple clusters.

Start by reviewing the Helm chart resources controlled by operator.rbac.scope, especially the ClusterRole and ClusterRoleBinding, and compare them with the proposed Role and RoleBinding model. Examine how repeated subchart installations interact with resource ownership and shared CRDs. Done should include a decided support scope that addresses namespace isolation, installation conflicts, and CRD version uniformity.