ClusterRoles and ClusterRoleBindings

Roles lock you inside one namespace. That's not a workaround; it's a hard constraint of the Kubernetes API model. Node, PersistentVolume, Namespace, StorageClass, ClusterRole: none of these resources belong to a namespace, so a Role can't grant access to them. Non-resource URLs like /metrics and /healthz don't belong to a namespace either. If you need those, you need a ClusterRole.

But cluster-scoped access isn't the only reason ClusterRoles exist. The binding asymmetry makes them the right tool for a second pattern: a permission template you define once and bind per-namespace with a RoleBinding. One ClusterRole, many namespaced grants. That's how the default edit and view ClusterRoles work, and it's the same mechanism that lets operators like Flux extend built-in roles to cover their CRDs automatically.