[Feature]: Migrate all RBAC related resources to Helm chart's templates

[arbreezy]

Checklist

• I've searched for similar issues and couldn't find anything matching
• I've discussed this feature request in the K8sGPT Slack and got positive feedback

Is this feature request related to a problem?

None

Problem Description

Both manager's and k8sgpt's roles have to match in order for the former to grant permissions to K8sgpt cluster role or add the verb escalate. Following the Least privileged access idiom, would be great if we move away from the existing way of managing roles

Solution Description

Lift and shift the cluster role, bindings and service account from operator's code to Helm chart's tempates

Benefits

To be more transparent to the end users and also avoid situations like K8s API restrictions with roles which caused issues in the latest v0.0.22

Potential Drawbacks

No response

Additional Information

No response

[MateSousa]

hi @arbreezy, can i do ?

[MateSousa]

hey @arbreezy, just to make sure I got it right, i need to migrate all the RBAC from this folder config/rbac to the helm template, right?

[arbreezy]

Hello @MateSousa let me elaborate a bit more,

At the moment we are creating with the controller the K8sGPT's role, rolebinding and service account.

There are two issues with this approach,

1. The controller's role we define here has to match the K8sGPT's role permissions otherwise K8s API disallow the creation, although controller doesn't need those perms for its own workload
2. In terms of readability, we want to surface those role and rolebinding and service account resources in the chart

So the proposed solution is to move them out of our codebase and include them as part of the chart's template folder
then in the deployment struct we will just reference the service account name (as we already do)