Team isolation in OSS with a shared Prometheus and a contractor
You administer Grafana OSS 11 for a company with four product teams and one platform team. All 220 users are in one organization, Main. Each team wants its own dashboards and data sources; Team A must not query Team B's Prometheus. You currently have one Prometheus data source with cluster-wide access, 300 dashboards in the General folder, and everyone has the Editor role because nobody had time to design permissions. A contractor needs read-only access to only Team A's dashboards for six weeks. A security review flags that any Editor can edit any dashboard and add a data source. You cannot buy Grafana Enterprise this quarter, and leadership wants a plan that improves isolation without a full re-platforming project.
1. Which isolation requirements can Grafana OSS satisfy, and which cannot? Be specific about data sources.
Read the worked answer
OSS can satisfy dashboard-level separation with folders and folder permissions, and it has teams and organizations. You can create a folder per product team, grant Team A Edit on its folder and View or None on others, and set the org default role to Viewer. That stops casual cross-team dashboard edits.
OSS cannot enforce data source permissions: there is no per-data-source permission model in OSS (that is an Enterprise feature), and any user who can query a data source can use Explore or build a panel against it. So 'Team A must not query Team B's Prometheus' is not achievable with one shared Prometheus data source in one org. Separate organizations are the OSS-native isolation boundary: each org has its own dashboards, data sources, alert rules, and users. But orgs are coarse, users can belong to multiple orgs, and server admins can switch them; they also duplicate administration. For the contractor, folder permission plus Viewer org role limits UI exposure but does not stop a determined user from querying the shared Prometheus through Explore.
2. Design an interim configuration for the four teams and the contractor using only OSS features. State the residual risk.
Read the worked answer
Interim design: create folders team-a through team-d and platform. Create teams matching each product team, and assign folder permissions: Team A Edit on team-a, View on platform if needed, and no permission on other folders. Change the organization default role from Editor to Viewer, then grant Edit only through team membership on owned folders. For the contractor, create a contractor-a team with View on team-a only, give the contractor the Viewer org role, and set a six-week expiry reminder; do not add them to any other team. Put dashboards that must be broadly visible in a separate folder with View for the org.
Residual risk: the shared Prometheus remains queryable by anyone with Viewer and Explore access, and Editors can still add data sources because OSS does not allow granular removal of that permission. Document that this is UI isolation, not data isolation. If the security review requires hard data-source separation, OSS folders cannot meet it.
3. What long-term options would you present, with trade-offs?
Read the worked answer
Option 1: Grafana Enterprise, which adds data source permissions and RBAC. It directly solves per-team data source restrictions and contractor scoping, but adds licensing cost and is the option you cannot buy this quarter.
Option 2: separate Grafana instances or stacks per team, each with only its own Prometheus and users. This gives hard isolation in OSS but multiplies upgrades, backup, and alerting administration; cross-team dashboards become copies or links. Option 3: keep one Grafana but put a multi-tenant query layer in front of Prometheus, such as Mimir or Cortex with per-tenant auth, and issue per-team data sources and credentials. This is strong for query isolation but requires platform engineering and does not fix dashboard edit permissions by itself. Option 4: Grafana Cloud with RBAC and data source permissions if SaaS is allowed. My recommendation: interim folders plus Viewer default now, plan Enterprise or per-team instances before the next security audit, and never claim OSS folders provide data-source isolation.