search

k8sgpt-ai / k8sgpt-operator

Automatic SRE Superpowers within your Kubernetes cluster
https://k8sgpt.ai
Apache License 2.0
315 stars 90 forks source link

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

Closed arbreezy closed 5 months ago

arbreezy commented 12 months ago

Checklist

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 commented 11 months ago

hi @arbreezy, can i do ?

MateSousa commented 11 months ago

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 commented 11 months ago

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)