RBAC support for isolating permissions for ResourceGraphDefinitions

[toweroy]

Feature Description

Problem Statement:
In order to give access to the different ResourceGraphDefinitions (RGD) that we want to support in our cluster (and that might also be owned by other teams than us), today we have to grant the kro controller access to ALL of the required apis, resources, etc… via a ClusterRole. This is becomes harder to maintain since all permissions get aggregated to one (kro) controller, and it also is a concern in regards of security/permission isolation (i.e. on controller holds all of the permissinons required for all the RGDs).

It would be great to have RBAC support in kro that could then allow use to isolate permissions depending on the different RGDs that will exist.

Proposed Solution:
Provide a way to define RBAC permissions in kro that allows for isolated permissions that only concern the specific RGD dynamic controller (I believe right now we create one per RGD?).

Alternatives Considered:
There are currently no good alternatives (that I know of) for avoiding giving all of the required permissions as an aggregate to the kro controller.

• Please vote on this issue by adding a 👍 reaction to the original issue
• If you are interested in working on this feature, please leave a comment

[ramonvermeulen]

[DISCLAIMER] I have to say that I am fairly new to kro, so please correct me if I am wrong, but I would like to offer some thoughts on this issue.

Especially from a platform engineering perspective I can understand a scenario where you would like to give different teams the responsibility to own a specific set of ResourceGraphDefinition's. I think the main challange here is that from a Kubernetes perspective, kro is currently running as a single "controller" with a single kubernetes SA tied to it (see how it is currently deployed as single controller via the helm chart for example).

In the controller itself it has the concept of the RGD Reconciler and the Dynamic Controller, where the RGD Reconciler manages the RGD object lifecycle and the dynamic controller manages the different RGD "kinds" (e.g. Application, Database, WebApp, or whatever composition you defined in your RGDs), however, these are in a sense software components.

Currently via the rbac.kro.run/aggregate-to-controller: "true" annotation all the ClusterRole's are aggregated into one ClusterRole that is attached to the kro SA. This role should at least have the permissions to manage the underlaying Kubernetes objects that are used in the RGDs for kro to work. However, if you have a large set of RGDs, the scope of this role will indeed drastically grow (as you are probably experiencing right now).

---

One of the solution directions I can think of to improve RBAC within kro:

Introduce RGD groups (or kro groups), essentially provisioning a single CRD controller per group (e.g. team, business unit, or other trust boundary).

An example of this on the resource definition side can be:

apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
  name: my-application
  labels:
    kro.run/group: <group-name>
    ...

The helm chart would then be deployed with a list of groups via the values.yaml, where every entry would provision a separate CRD controller (and rest of the current template resources). The controller will only reconcile RGDs for groups of it's own kind, and every group has it's own dedicated SA. Maybe a similar ClusterRole aggregation mechanism can be used on group level, for example via rbac.kro.run/aggregate-to-group:<group-name>.

When no groups are configured, the helm chart can provision a single default controller managing the default group.

If this direction aligns with the project's vision, I would be very interested to help design and implement this feature.

[shivansh-source]

@toweroy i would like to work on this issue