Permits to target a grafanaFolder in another namespace into the GrafanaDashboard CR

[aboulay-numspot]

Is your feature request related to a problem?

Context: We are trying to permits developers to deploy there dashboards and create folders in a restricted Kubernetes environment. Developers can only access a dedicated namespace and create resources inside it. The folders and dashboards should be deployed only in a specific folder using a dedicated service account with specific permission on it.

The potential deployment pattern is the following:

The advantage of this pattern is that it permits to target a folder only by it name + namespace without having it information. This protects the content access to the Grafana with "sa" service account and avoid to potentially be compromised on other Team Folder.

Currently, this is not possible to target the folder because folderRef in the GrafanaDashboard CR could only target a Folder in the same namespace.

Describe the solution you'd like

I would like to make an evolution on the GrafanaDashboard CRD to have the possibility to declare a namespace in addition of the folderRef field.

Potential patterns (to debate):

<...>
folderRef:
  name: team-1
  namespace: operator
<...>

<...>
folderRef: team-1
folderRefNamespace: operator
<...>

Describe alternatives you've considered

I have try different pattern using the operator or not (Terraform) to create this architecture (the Grafana view).
However, problem happened when:

• Folder Team-1 created using Terraform: A dashboard is destroyed and the parent folder destroyed at the same time (which mean I need to recreate it manually after this and an inconsistency in my Terraform state).
• GrafanaFolder created in the operator namespace with folderUID: inconsistency of the UID which make impossible an automated replication of the GrafanaDashboard resource with multiple kubernetes clusters.

Additional context

Using this pattern, in case of deletion of the parent Folder by the operator, the reconciliation loop will recreate the folder few minutes later.

I can present this during the next maintainer meeting if you want.

Existing solutions

N/A

[theSuess]

To reduce complexity, we'll focus on #1636 which allows stable UIDs