The Helm chart currently provides RBAC configuration options (link):
rbac:
enabled: false
additionalPolicyRules: []
However, these settings are only applied to the kubeblocks-rbac-manager-role ClusterRole (link). Meanwhile, other RBAC objects like the kubeblocks-rbac-role ClusterRole are created unconditionally, regardless of the actual permissions needed.
This creates unnecessary RBAC objects that may grant excessive permissions beyond what's required for basic kubeblocks functionality (creating and managing database clusters). For example, does the kubeblocks-manager really need to operate on kind: Role objects?
I suggest: Apply the same configuration pattern (similar to the one referenced here) to all RBAC resources, allowing users to enable/disable creation of each RBAC object. When disabled, users would be responsible for creating and managing these RBAC resources outside of the chart.
The Helm chart currently provides RBAC configuration options (link):
However, these settings are only applied to the
kubeblocks-rbac-manager-roleClusterRole (link). Meanwhile, other RBAC objects like thekubeblocks-rbac-roleClusterRole are created unconditionally, regardless of the actual permissions needed.This creates unnecessary RBAC objects that may grant excessive permissions beyond what's required for basic kubeblocks functionality (creating and managing database clusters). For example, does the
kubeblocks-managerreally need to operate onkind: Roleobjects?I suggest: Apply the same configuration pattern (similar to the one referenced here) to all RBAC resources, allowing users to enable/disable creation of each RBAC object. When disabled, users would be responsible for creating and managing these RBAC resources outside of the chart.