Condense RBAC rules autogenerated by kubebuilder

[mflendrich]

Is there an existing issue for this?

• I have searched the existing issues

Problem Statement

See if the RBAC rules generated by kubebuilder here could be condensed into fewer lines for more readability.

Proposed Solution

TBD

Additional information

No response

Acceptance Criteria

• Improved readability/auditability of k8s RBAC rules that we install in user's cluster

[mflendrich]

@hbagdi says:

You don’t need permissions on events in Role resource. ClusterRole resource covers them already.

[mflendrich]

Also @hbagdi says:

If we don’t use lease resource, why do we have rbac for it? I couldn’t find the lease resource in code or in the cluster. I could be very wrong here. Does controller runtime make use of it? Why do I not see it in the cluster? Maybe I’ll if I deploy using postgres?

[hbagdi]

Here are my condensed versions: https://gist.github.com/hbagdi/4aba056bb8c96c29d368a9c6eb997a8a
https://gist.github.com/hbagdi/1e9810283c153b20d70cd336b182fcca
Feel free to copy them. Please verify if you do so.

[shaneutt]

Breaking down all the files from this directory, since the entire directory was linked in the description:

Auth Proxy

These RBAC rules (and the relevant Service) are automatically generated when a kubebuilder init initializes a new project, and they provide access controls to restrict usage of the controller manager metrics endpoints.

Ultimately since they're part of kustomize deployment which we use only for simple tests and examples these are mostly for posterity, but that posterity is important and I don't see any reason to change these.

Viewer and Editor Roles

Each one of the <api-type>_viewer_role.yaml and <api-type>_editor_role.yaml RBAC rules provided are one-time generated manifests from kubebuilder which are meant for cluster operator consumption (e.g. an operator can give fine-grained permissions).

I see no reason to change these from what kubebuilder provides as they seem simple and well named.

Leader Election Role

This role and binding are also generated by kubebuilder init in order to support the controller manager.

@hbagdi you suggested a condensed version which looked nearly identical to what's currently present, minus a namespace. Similar to above, these RBAC rules are mostly used for posterity and we reference them chart deployments:

https://github.com/Kong/charts/blob/main/charts/kong/templates/controller-rbac-resources.yaml#L44

There we specify the templated namespace.

I don't see any compelling reason to make changes here: as with most of our kustomize configs this is for example and we derive from it in the chart, and the rules do specifically help make leadership election possible.

Manager Role

The main manager role could be condensed as suggested above but with current controller-gen this will mean that we no longer get this file automatically generated for us when we run make manifests, nor will it be lint check-able in CI (the rbac options for controller-gen take no option to compile all rules into a condensed form as shown above).

I do not feel we should be manually maintaining this file for multiple reasons:

• we've already invested significant time to getting the generators for this right
• this manifest is not of significant consequence to end-users: they deploy it but it's an implementation detail of the controller manager, not a role they are meant to specifically bind to or interact with

---

I don't see the impetus for change in these or any of the existing roles. If condensing them could be done via the automation we have in place to create and maintain them, that would be fine. We could make upstream improvements to controller-gen to make the emitted manager role cleaner, for instance, however I don't think this should be a blocker for KIC 2.0 if anything just a "nice to have" for some time when we have free time.

I propose the following new action items to consider this issue resolved, as opposed to making any changes to the files:

• we spin up an upstream issue for improvements to controller-gen to produce a single condensed section for rbac roles as an option instead of the historical separate sections
• we add a README.md to the config/rbac directory which provides some of the above context to help readers of the repository navigate this directory and understand where/why/how these files are used and created.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.