Default cluster role rules for CRDs?

[plobsing]

After installing the operator and instantiating an instance, I was surprised to find that I could not view or interact with the operator's resources except when acting as cluster-admin. It seems that while the CRDs were installed, no corresponding ClusterRoles were set up to allow appropriate roles to read and/or update them.

By contrast, the Flux instance installed by the operator did have cluster roles set up with aggregation set up to grant the usual levels of access to Kubernetes' default cluster roles — view is granted get, list, and watch operations; edit and admin are granted the full complement.

It seems oddly inconsistent that the default install and usage of the Flux operator allows the built-in Kubernetes roles their normal level of access to resources like GitRepository or Kustomization, but does not provide any access to FluxInstance or FluxReport.

I see that there are cluster role configurations for granting granular access to the operator's resources in this repo, but it seems they are not installed be default, it is not clear how they should be installed (can't find any mention on https://fluxcd.control-plane.io/operator/), and they don't seem to set up aggregation to the Kubernetes built-in roles.

What's the intent here? Should the operator install cluster roles to make its resources interactable to non-cluster-admin users? Should that be left to individual installs to set up? Should the instantiated Flux's dispostion be the same or different?

Install details

Installation method: Terraform
Chart version: v0.13.0
Flux distribution: ghcr.io/fluxcd v2.4.0
Cluster type: aws
Kubernetes version: v1.31.4-eks-2d5f260

[stefanprodan]

A FluxInstance can only be managed by cluster admins and can only be deployed once per cluster in the same namespace as the operator, given this I don’t see why would we want an aggregation rule for it.