This message was deleted.

AI ?

...just trying to confirm

@hundreds-sugar-37524 no AI

We do use argocd to deploy a bunch of CRTB and Projects/PRTB but we faced an issue. I opened [BUG] missing project membership in case of duplicate group and project name but different clusters · Issue #53559 · rancher/rancher with as much details as possible a few months ago. I will replace the globaRole with a few CRTB to limit our operators rbac

@hundreds-sugar-37524 This aligns with a fairly common RBAC boundary issue in multi-cluster Rancher setups. Moving away from a broad-scoped globalRole and instead expressing access via ClusterRoleTemplateBindings (CRTBs) per downstream cluster is generally the correct approach when you need strict tenant isolation across clusters. In practice, this lets you bind your operator service identities directly to per-cluster ClusterRoleTemplates, so authorization is evaluated within the scope of each downstream cluster rather than inherited globally through Rancher’s management-plane RBAC layer. This also plays much better with GitOps workflows like ArgoCD, since you can declaratively manage CRTBs alongside Projects/PRTBs, and ensure that project-level constraints don’t bleed across clusters via duplicated group/project name resolution — which is consistent with the issue you referenced. Your plan to replace globalRoles with cluster-scoped CRTBs should help reduce cross-cluster privilege propagation, especially for operators watching CRDs like CNPG or Argo applications. If you hit any edge cases during rollout (especially around project membership resolution or group-to-principal mapping), I’m happy to help dig into them.