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

@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.

from grafana-operator.

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).

from grafana-operator.

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.

from grafana-operator.

I think for operator it should not matter if it is running in WATCH_NAMESPACE or all namespaces mode. It is not about access rights of the operator, if I understand correctly, for all namespaces mode it runs under cluster-admin role anyway.

Limiting allowCrossNamespaceImport is not the solution, as on GrafanaDashboard/GrafanaDatasource side, the allowCrossnamespaceImport is set legitimately. The problem is:

• User A has Grafana instance in namespace A1 and GrafanaDatasource in namespace A2
• Grafana in namespace A1 has selector app: grafana-a1
• User A sets up allowCrossNamespaceImport: true for the GrafanaDatasource in namespace A2, which gets imported into Grafana with selector grafana-a1 in namespace A1, as expected
• User B (who does not have any access to namespace A1 or A2) sets up a Grafana in namespace B1
• User B assigns a selector grafana-a1 to its Grafana in namespace B1
• operator imports GrafanaDatasource from namespace A2 to Grafana in namespace B1
• User B now has access to user's A data

There is nothing User A can do about this. Even if he sets acceptResourcesFromNamespace on its Grafana instance in A1, he does not even know that there is a Grafana in namespace B1, and user B is still able to access user A datasource from his Grafana instance.

This is a major security issue.

To avoid this, we should follow RBAC logic, e.g. GrafanaDatasource/GrafanaDashboard should be able to declare from what namespaces Grafana should be considered.

So I see one of two possible solutions:

• (RBAC) - when grafana operator finds a Grafana instance that complies with instanceSelector of a GrafanaDatasource/GrafanaDashboard, it checks that the service account of the Grafana instance has access rights to the GrafanaDashboard/GrafanaDatasource in that namespace, via standard RBAC API. Possible optimization would be not to this if both are in the same namespace
• (CR) - in addition to existing instanceSelector on GrafanaDashboard/GrafanaDatasource CR, which identifies Grafana instance by labels (in all namespaces), introduce also a namespaceSelector (or use existing namespace if not specified), which would limit Grafana instances by namespace, in addition to the instance selectors. You could identify the namespace either by labels or by name, I think this is a standard Kubernetes pattern. This way, we could even retire allowCrossNamespaceImport, as if no namespace selector would be specified, only the current namespace would be considered for import.

from grafana-operator.

This issue hasn't been updated for a while, marking as stale, please respond within the next 7 days to remove this label

from grafana-operator.