Grafana dashboards UseCases: #2776

Chernosov Denis (dvc) · 2026-06-01T11:16:49Z

Chernosov Denis (dvc)
Jun 1, 2026

Grafana Dashboards usage in CozyStack clusters

Context

In CozyStack GrafanaDashboard CRs from grafana-operator used for install dashboards.

By default Grafana and GrafanaDashboard CRs must be placed in same namespace.

There are 2 lists in main CozyStack package:

dashboards-infra.list - for namespaces "tenant-root", "cozy-monitoring" only
dashboards.list - for any tenant

GrafanaDashboard are copied into all tenants with monitoring: true.

It is not the best practice:

Bad UX - empty dashboard if dependent package is not installed
SingleResponcibilityPrinciple is broken:
- need to update whole package for changes in any dependent applications.
- Duplication of entities with same responcibility

Another problem: lack of user stories about multi-tenancy monitoring as a service. How users can deploy custom dashboards in one or many Grafana instances?

N.B.! This document meant multi-tenancy access to shared Grafana, but do not describe details of it.

Proposal

GrafanaDashboard behavior can be changed by allowCrossNamespaceImport: true setting. In activate ability to deploy GrafanaDashboard and target Grafana CRs in different namespaces. And using single GrafanaDashboard for multiple Grafana.

Case 1. Install dashboard in all Grafana in cluster.

For example, for tenant apps, like FlinkDeployment. Place CR in system/flink-operator package:

---
apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDashboard
metadata:
  name: flink
  namespace: cozy-grafana-operator
spec:
  folder: flink
  instanceSelector:
    matchLabels:
      dashboards: grafana
  # search Grafana in all ns
  allowCrossNamespaceImport: true
  json: >
    {
      ...

Case 2. Install in tenant-root (infra)

For system apps only. For example, FlinkOperator self metrics dashboard. Place CR in system/flink-operator package too:

---
apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDashboard
metadata:
  name: flink-operator
  # will be installed successfully before tenant creation
  namespace: cozy-grafana-operator
spec:
  folder: flink
  instanceSelector:
    matchLabels:
      dashboards: grafana
      # add filter  "tenant-root" for all infa-dashboards
      helm.toolkit.fluxcd.io/namespace: tenant-root
  # search Grafana in all ns
  allowCrossNamespaceImport: true
  json: >
    {
      ...

Case 3. Install to single tenant Grafana instance.

For example, team DataLake wants to install self-served dashboard in parent tenant (tenant-prod) with monitoring. Install GrafanaDashboard in tenant-prod-datalake:

---
apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDashboard
metadata:
  name: flink-datalake
  # installed manually or via GitOps with other command manifests:
  namespace: tenant-prod-datalake
spec:
  folder: flink-datalake
  instanceSelector:
    matchLabels:
      dashboards: grafana
      # add filter by tenant with active monitoring
      helm.toolkit.fluxcd.io/namespace: tenant-prod
  # search Grafana in all ns
  allowCrossNamespaceImport: true
  json: >
    {
      ...

Results

This schema allow to deploy dashboards with their applications, in tenant-agnostic manner.

Users custom dashboads are supported too. They can use GitOps and deploy dashboards in different NS with Grafanas.

Risks

For secure users dashboards support, some hardening needed: RBAC, manifests validation rules, multi-tenancy Granafa access, grafana orgs and/or folders usage conventions, etc.

Timur Tukaev (@tym83) fyi

Chernosov Denis (dvc) · 2026-06-01T11:48:52Z

Chernosov Denis (dvc)
Jun 1, 2026
Author

Same story should be valid for VMRule/VMAlert

0 replies

Aleksei Sviridkin (lexfrei) · 2026-06-03T10:09:31Z

Aleksei Sviridkin (lexfrei)
Jun 3, 2026
Maintainer

This lines up with a monitoring epic I've been tracking in #2194 — item 3 there is exactly "all tenants receive infrastructure dashboards", the copy-into-every-tenant behaviour you're describing. So the problem is acknowledged, and your write-up is a good articulation of the dashboard side of it.

On the mechanism: allowCrossNamespaceImport: true + an instanceSelector is the grafana-operator-native way to do this, and shipping the GrafanaDashboard from the same package as the app (your Case 1/2) is the right single-responsibility fix — it kills both the empty-dashboard UX and the update-the-whole-package coupling. VMRule/VMAlert should follow the same pattern via the vmoperator selectors.

The crux is Case 3 / your Risks section: once allowCrossNamespaceImport is on, a GrafanaDashboard is only as isolated as its instanceSelector. For tenant-authored dashboards we can't rely on that selector being well-behaved — a tenant could target another tenant's Grafana unless the scoping is enforced, not conventional. So the hard part isn't the cross-namespace import, it's the multi-tenancy guardrail around it: constraining which Grafana a given namespace's dashboards may select (admission/validation + a label/RBAC convention the tenant can't escape). That's the piece that needs a design before this can be on by default.

Two adjacent items from the same epic, since they came up together:

Per-tenant log routing — tenant VLogs currently receive nothing, everything goes to the parent. Tracked as [monitoring] Improve multi-tenant log isolation, dashboard scoping, and VM monitoring #2194 (item 1) with feat(monitoring): auto-route tenant logs using namespace labels #2195.
Infra metadata leaking into logs (node name etc.) — [monitoring] Improve multi-tenant log isolation, dashboard scoping, and VM monitoring #2194 (item 2) / fix(monitoring): strip infrastructure metadata from tenant logs #2196.

Proposal: fold the dashboard-scoping design into #2194 (or split it into its own issue under that epic if it grows), and use this thread to settle the tenant-isolation model for allowCrossNamespaceImport specifically.

2 replies

Chernosov Denis (dvc) Jun 3, 2026
Author

a tenant could target another tenant's Grafana unless the scoping is enforced, not conventional

may be wrap it into GrafanaDashboard.cozy CRD as user app? Like app Bucket for extra/SeaweedFS. It could be place to found target tenant monitoring. And may be add it to tenant folder or org? User creds also could be here (or OIDC integration).

Aleksei Sviridkin (lexfrei) Jun 3, 2026
Maintainer

Good direction — wrapping tenant-authored dashboards in a Dashboard app (à la Bucket) is exactly the enforcement layer this needs. The key insight: a raw GrafanaDashboard lets the author pick any instanceSelector, which is "conventional" isolation; an app whose controller renders the underlying GrafanaDashboard with a selector pinned to the tenant's own Grafana is "enforced" — the tenant can't escape it. That closes the Case 3 gap.

A couple of constraints from grafana-operator v5 (we ship v5.13.0) worth designing around:

Folders: yes. GrafanaFolder + folderRef/parentFolderRef are native, so per-tenant folders are straightforward. GrafanaFolder.permissions (raw JSON) exists for folder-level RBAC, but fine-grained folder RBAC depends on the Grafana edition/RBAC features in the build — needs verifying before we lean on it.
Orgs: no. v5 dropped organization management (no org CRD). So the "tenant org" part of the idea isn't reachable through the operator — we'd be limited to folders, or to a one-Grafana-per-tenant layout.

That splits cleanly into two models. With Grafana-per-tenant (current layout), isolation is namespace + a forced instanceSelector; the wrapper controller just pins it, no orgs needed. With a single shared Grafana, you'd isolate by org/folder — but that's the path the operator supports least today.

So I'd scope the wrapper around the per-tenant-Grafana model first: a tenant-facing Dashboard CR whose controller emits a GrafanaDashboard with allowCrossNamespaceImport + an instanceSelector it controls, optionally into a per-tenant GrafanaFolder. Credentials/OIDC I'd keep out of the dashboard CR and tie to the existing tenant Grafana wiring. App-shipped dashboards (Case 1/2) stay as plain GrafanaDashboard from their package — those are operator-authored and trusted, no wrapper required.

Chernosov Denis (dvc) · 2026-06-04T08:07:28Z

Chernosov Denis (dvc)
Jun 4, 2026
Author

Orgs: no. v5 dropped organization management (no org CRD). So the "tenant org" part of the idea isn't reachable through the operator — we'd be limited to folders, or to a one-Grafana-per-tenant layout.

orgs are about "case 4: allow users ad-hoc dashboards manipulating". Any tenant manager logged in tenant grafana as admin/editor in tenant org. And can create/update/delete dashboards by hands. Kind of sandbox. It's hard to scale story, but looks "user friendly".

0 replies

Navigation Menu

Repository navigation

Grafana dashboards UseCases: #2776

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 3 comments 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Select a reply

Uh oh!

Grafana dashboards UseCases: #2776

Uh oh!

Uh oh!

Chernosov Denis (dvc) Jun 1, 2026

Grafana Dashboards usage in CozyStack clusters

Context

Proposal

Case 1. Install dashboard in all Grafana in cluster.

Case 2. Install in tenant-root (infra)

Case 3. Install to single tenant Grafana instance.

Results

Risks

Replies: 3 comments · 2 replies

Uh oh!

Chernosov Denis (dvc) Jun 1, 2026 Author

Uh oh!

Aleksei Sviridkin (lexfrei) Jun 3, 2026 Maintainer

Uh oh!

Chernosov Denis (dvc) Jun 3, 2026 Author

Uh oh!

Aleksei Sviridkin (lexfrei) Jun 3, 2026 Maintainer

Uh oh!

Uh oh!

Chernosov Denis (dvc) Jun 4, 2026 Author

Chernosov Denis (dvc)
Jun 1, 2026

Replies: 3 comments 2 replies

Chernosov Denis (dvc)
Jun 1, 2026
Author

Aleksei Sviridkin (lexfrei)
Jun 3, 2026
Maintainer

Chernosov Denis (dvc) Jun 3, 2026
Author

Aleksei Sviridkin (lexfrei) Jun 3, 2026
Maintainer

Chernosov Denis (dvc)
Jun 4, 2026
Author