Fine-grained RBAC controls in the Helm chart

[tomasaschan]

Feature Description

Problem Statement:
The Helm chart currently creates a cluster role with full permissions on everything, and a cluster role binding to the KRO service account for that cluster role; while practical, it is also going to be way overspecified in most production environments. The Helm chart should support more fine-grained control of permissions assigned to KRO - or, at least, support turning off the super-admin permissions and allow the user to manage RBAC separately.

Proposed Solution:
A parameter to the Helm chart that turns off cluster-level RBAC for KRO, with documentation for how to set up permissions manually.

Alternatives Considered:
The Helm chart could also be given parameters for exactly what permissions to include in the role, but that is probably no easier to specify than just using the RBAC resources directly, so not sure if it's worth the complexity in the chart.

• Please vote on this issue by adding a 👍 reaction to the original issue

[Gonfidel]

The chart already supports passing a service account using serviceAccount.create=false and serviceAccount.name=YourServiceAccountName.

This would allow someone to create their own service account out of band with their preferred permission set and apply it to the controller. To your point though, we probably shouldn't create the ClusterRole and ClusterRoleBinding if we aren't going to use the default service account.

Am I am misunderstanding the reported issue or maybe this satisfies the need and we should document it along with the required minimum permissions?

[tomasaschan]

@Gonfidel Nice, I had not seen those parameters! But if the role/binding are created anyway, I'd say it's not good enough - if they were also excluded, I'd consider it non-blocking, but still poor UX. I don't have a need to use a different SA, so I'd rather have a way to say createAdminBindings=false than having to create a different SA and tell the chart to use it.

I think the pattern used by Kyverno is pretty neat: for each SA it uses, it creates an aggregating cluster role, allowing users to create cluster roles and have them apply to the appropriate SA simply by means of adding a label to the role. I think this is a pattern both simple and powerful enough that it's worth emulating. https://kyverno.io/docs/installation/customization/#clusterroles