ClusterRoles and RoleBindings are usually written last, as a compliance step, with the widest permissions that make the error go away. That inverts the value. If you write RBAC first as a design step, it forces you to enumerate what a service actually needs to do. That enumeration is more valuable than the security boundary itself.
For k3s-dashboard, the backend needs to list nodes, deployments, statefulsets, daemonsets, replicasets, and events cluster-wide. Writing that out as a ClusterRole before writing any backend code made the API surface explicit. When a new endpoint was needed, updating the ClusterRole first became an intentional gate that kept privilege scope visible as the project grew.
The anti-pattern is granting cluster-admin to make something work and moving on. You have destroyed the documentation. You no longer know what the service actually needs, only that it needs everything. That gap does not show up until an audit, an incident, or a new engineer tries to understand what this service is allowed to touch.