[Bug] Installing as a lower privileged user in namespace-scoped mode fails due to OpenShift resources in generated Role

[yaraskm]

Describe the bug
This is closely related to #1330. Since a vanilla Kubernetes cluster does not have the OpenShift resource type routes, namespace-scoped installation as a user without cluster admin permissions fails due to trying to grant permissions in a Role not currently held.

Version
v5.5.2

To Reproduce
Steps to reproduce the behavior:

1. Configure kubectl such that your are connecting to a cluster as someone who does not have admin permissions at the cluster scope.
2. Attempt a helm install in namespace-scoped mode: helm upgrade -i grafana-operator oci://ghcr.io/grafana-operator/helm-charts/grafana-operator --version v5.5.2 -n tester --set namespaceScope=true

Expected behavior
The install should succeed with a generated Role that does not contain these OpenShift resource types.

Suspect component/Location where the bug might be occurring
https://github.com/grafana-operator/grafana-operator/blob/921a4da76410b7d1cc56d31da14a03859dc688fb/deploy/helm/grafana-operator/templates/rbac.yaml#L207-L218

Screenshots
Output of a test installation:

$ helm upgrade -i grafana-operator oci://ghcr.io/grafana-operator/helm-charts/grafana-operator --version v5.5.2 -n tester --set namespaceScope=true
Error: UPGRADE FAILED: failed to create resource: roles.rbac.authorization.k8s.io "grafana-operator-permissions" is forbidden: user "..." (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:["route.openshift.io"], Resources:["routes"], Verbs:["create" "delete" "get" "list" "update" "watch"]}
{APIGroups:["route.openshift.io"], Resources:["routes/custom-host"], Verbs:["create" "delete" "get" "list" "update" "watch"]}

Runtime (please complete the following information):

• OS: Linux
• Grafana Operator Version: v5.5.2
• Environment: AKS v1.24, though this is repeatable on other cluster types
• Deployment type: Helm deployment
• Other: N/A

Additional context
This could possibly be solved by only creating the rules for the routes types if they exist in the cluster using Capabilities.APIVersions.Has: https://helm.sh/docs/chart_template_guide/builtin_objects/

[weisdd]

Even though it makes sense, it's a bit tricky to implement, because not all helm commands lead to actual interaction with a cluster. E.g. if someone uses helm only for templating (helm template without additional flags), the end result would not include the routes section. So, it's up for a discussion.

@NissesSenap WDYT?

[yaraskm]

Even though it makes sense, it's a bit tricky to implement, because not all helm commands lead to actual interaction with a cluster. E.g. if someone uses helm only for templating (helm template without additional flags), the end result would not include the routes section. So, it's up for a discussion.

@NissesSenap WDYT?

Perhaps a compromise could be a value argument isOpenShift that must be set to true to add any resources related to OpenShift explicitly? That bypasses any differences in how the helm subcommands would treat the templates.

[NissesSenap]

You more or less have to have cluster access since you installed a CRD, but I guess in some setup you could setup the CRDs in separate solutions and then setup grafana instances in namespace mode.

My guess is that we have rather few openshift users that are running helm since most of them will use OLM.
I have seen many operators that force openshift users to define a specific flags, and it sounds like an easy enough solution.

We would love a PR around this.