Unable to limit which Grafana can use which dashboards (v5 operator) about grafana-operator

[pb82]

@bukovjanmic if I understand correctly, you are using a single instance of the Operator to manage Grafana instances and dashboards across a number of namespaces.

In that case WATCH_NAMESPACE and the proposed WATCH_NAMESPACE_SELECTOR won't help, because they limit the Operator itself to one or a number of namespaces.

You could probably work with roles and rolebindings per Grafana instance serviceaccount, but that becomes hard to manage.

A field acceptResourcesFromNamespaces on the Grafana CR could work, we can discuss this on our next triage call.

[bukovjanmic]

Yes, correct.

We discussed this as well and we think RBAC for the resources is the way to go, the operator should check if the Grafana instance service account has access right (RoleBinding) to the GrafanaDashboard/GrafanaDatasource resource.

acceptResourceFromNamespace will not solve the problem with malicious users - user could still create a Grafana instance, set acceptResourceFromNamespace to someone elses namespace and if he knows the correct labels, he can steal GrafanaDatasource credentials from GrafanaDatasource in namespace that he normally does not have access to (but Grafana operator does).

[NissesSenap]

I don't really understand why it isn't enough with using built in RBAC, if you are running the operator in namespace mode you will have to provide the operator SA with correct access to watch going on in a specific namespace when using WATCH_NAMESPACE.
Or is it that you don't want to do that work, and you want to still use cluster level access for the operator?

This is a general issue in Kubernetes, and multiple operators have this issue. ArgoCD and Flux are both examples of this.

Personally, I don't think we should implement any solution around this in the operator, since it will increase the complexity of the operator. Potentially using something like acceptResourcesFromNamespaces, is simple enough but start doing a bunch of RBAC "magic" on the side is a slippery slope.

Instead, I would suggest using a tool like OPA or kyverno to make sure that allowCrossNamespaceImport: true can't be set.
Here is an example on how my old work used to enforce extra security around flux.
Just like, you need to make sure that ArgoCD applications can't use any projects you want.

I think we could write a blog on how to enforce OPA/kyverno settings, but I don't think it's something that we should solve in the operator using code.