Helm chart >=5.22.0: `namespaceScope=true` still requires ClusterRole/ClusterRoleBinding

[peterbueschel]

Describe the bug

After upgrading the grafana-operator Helm chart to 5.22.0+ (tested 5.22.2) and deploying with namespaceScope=true, the chart RBAC flow appears to be oriented around ClusterRole/ClusterRoleBinding.

The previously expected namespace-scoped Role + RoleBinding is not created anymore, so in clusters without permission for cluster-scoped RBAC the operator cannot reconcile Grafana CRs.

Version

Helm chart to 5.22.0+

To Reproduce

Steps to reproduce the behavior:

1. Install/upgrade grafana-operator Helm chart to 5.22.2
2. Set namespaceScope=true (namespace-only installation)
3. Install into a cluster where creating ClusterRoles is forbidden
4. Observe operator reconciliation failures

Expected behavior

With namespaceScope=true, the chart should create Role + RoleBinding and must not require any cluster-scoped RBAC (ClusterRole/ClusterRoleBinding).

Suspect component/Location where the bug might be occurring

This looks introduced by commit:
04eb1ca

Screenshots

Runtime (please complete the following information):

• OS: Linux
• Grafana Operator Version: v5.22.2
• Environment: Kubernetes
• Deployment type: Helm

Additional context

This is a common setup for namespace-scoped operators in restricted multi-tenant clusters; requiring cluster-scoped RBAC breaks upgrades for those environments.

[Baarsgaard]

We indeed did change the RBAC around to always use a ClusterRole, but when namespaceScope=true RoleBindings are created in the current namespace and namespaces in watchNamespaces.

A RoleBinding can bind a ClusterRole to a Service account, and when that happens, the permission scope is bounded to the namespace, despite it being a ClusterRole.
So functionally it's idential to before the change.

You can see an example of this in the RBAC documentation:
https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-example

In an restricted cluster, denying the creation of ClusterRoleBinding alone should be enough?

I could be very wrong in this, so please do elaborate on your use case if the above is incorrect or doesn't apply to you 😄

[peterbueschel]

Hi Baarsgaard,

A RoleBinding can bind a ClusterRole to a Service account, and when that happens, the permission scope is bounded to the namespace

That's for sure and correct.

However, the issue is mainly about the ClusterRole, which will be created even we set namespaceScope=true.
The versions >= 5.22.0, are generating always a clusterRole via "rbac.yaml":

kind: ClusterRole

Before, the template generates depending on the namespaceScope setting, "just" a role:

kind: {{ if not $namespaceScoped }}Cluster{{ end }}Role

---

In order to create a clusterrole you would need cluster admin permissions.

In our environment we are allowed to create only Role and RoleBinding (namespaced RBAC). Any attempt to create/update cluster-scoped RBAC (including ClusterRole) is forbidden.

So denying ClusterRoleBinding alone is not sufficient — the installation already fails at ClusterRole reconciliation.

(The CRDs are handled a bit differently - but that's a different story)

[Baarsgaard]

@peterbueschel So I spent some time thinking this through.

From one point of view, the Grafana-Operator has a significant number of permissions in order to handle the lifecycle of Deployments, ConfigMaps, Secrets, etc.
So from a security perspective, it could be seen as intended friction.
More reviews of what is being installed is not bad.

That said, us implicitly saying that CD solutions should be given create/delete permissions for ClusterRoles is probably not a good idea. It could technically be abused to replace existing ClusterRoles with additional permissions.

I'll discuss this with the other maintainers in the weekly public meeting tomorrow and hear what they think.

[Baarsgaard]

@peterbueschel I did not manage to make it to the meeting, but the other maintainers agreed to fix it, or at least allow a way to avoid the ClusterRole

[peterbueschel]

Thanks for the update.

I have also seen the discussion on the related PR and will try to address the new requirements.