ClusterRole: Tighten over-provisioned ConfigMap ClusterRole permissions

[dttung2905]

What you would like to be added?

Tighten ClusterRole configmaps permissions so each KAI component only gets the verbs it actually needs:

• Remove ConfigMap access entirely from Fix(clusterRole): - Remove ConfigMap access entirely from kai-admission, queuecontroller, kai-podgroup-controller, and kai-node-scale-adjuster #2061
  • kai-admission
  • queuecontroller
  • kai-podgroup-controller
  • kai-node-scale-adjuster

The reason is that they never use the ConfigMap API; current full CRUD is leftover leader-election scaffolding.

• Limit kai-scheduler and kai-podgrouper to get/list/watch (they only read ConfigMaps for scheduling predicates / optional defaults).

• Leave kai-binder and kai-operator ConfigMap write permissions unchanged (they create/manage ConfigMaps as part of normal operation for pod in any of the namespace where the workload is created).

• Regenerate Helm RBAC manifests from updated +kubebuilder:rbac markers and add chart unit tests so the least-privilege rules do not regress.

Why is this needed?

Several ClusterRoles currently grant cluster-wide configmaps verbs (get/list/watch/create/update/patch/delete) via ClusterRoleBindings, so a compromised or buggy component can read and mutate ConfigMaps in every namespace.

Those write verbs come from leftover +kubebuilder:rbac markers next to lease-based leader election scaffolding and are merged by controller-gen even though the components already have coordination.k8s.io/leases permissions and do not need ConfigMaps for leader election. Reducing unused cluster-wide ConfigMap access lowers blast radius without changing binder/operator behavior.

I will make changes to this tomorrow