Grafana Viewer role can query any org data source, beyond what dashboards expose

A security write-up published on dev.to draws attention to a widely misunderstood boundary in Grafana deployments: users holding the Viewer role are not limited to the queries baked into the dashboards they can open. According to the post, which cites Grafana's own security documentation, a Viewer can issue queries against any data source configured in the organization — including through the Explore interface or crafted API requests.

Dashboard visibility is not data access

Grafana reaches databases, log stores, metrics backends and APIs through data source connections, and a built-in proxy forwards requests to those services on behalf of a user or service account. The post argues this makes dashboard visibility and data source authority two separate questions. A panel that hides or omits a sensitive field only controls presentation; it does not constrain what a Viewer can ask the underlying connection to return. What Grafana can retrieve is decided by the credentials stored with the data source, while who may use the connection is decided by the data source permission model — a model many deployments leave broadly open.

Inventory and restrict the proxy paths

The write-up's first recommendation is an audit. Every data source carries a URL, a proxy setting, an authentication method and a set of allowed users or teams, and each represents a network route from Grafana's backend. Connections that can reach internal metadata services, administrative APIs or shared databases are called out as especially valuable targets.

At the host and network layer, the post advises restricting outbound destinations, maintaining a denied list covering cloud metadata endpoints, loopback addresses and administrative networks that no dashboard needs, and routing external traffic through a dedicated proxy or egress gateway. Where the deployment supports it, operators should log the destination, response status and user identity for each proxied request.

Data sources should also be separated by trust boundary rather than shared: a production finance database, a development metrics store and a shared log cluster should not all be reachable through one broadly granted connection. Each data source deserves its own service identity with the minimum permissions it needs, and read-only credentials should be preferred where the backend supports them.

Tighten query authority

According to the post, Grafana Cloud and Grafana Enterprise expose a data source permission model that can limit who queries, edits or administers a connection, assignable to users, teams and roles. In self-managed deployments, role design and the installed version's feature set determine which controls actually exist, so admins should check their edition rather than assume dashboard permissions are enough.

The author also cautions against blanket grants driven by labels or attribute-based access, and recommends verifying the effective query path with an account that has only Viewer access: run a query outside the dashboard, try a different time range, and make a direct API call against the data source proxy. High-privilege database credentials do not belong in a shared data source when a more limited forwarding identity will do, and if users must query a shared database, tenant or row-level restrictions should be enforced in the database role itself. Visibility configured inside Grafana is not a replacement for authorization enforced in the database.

Treat dashboards as code

Dashboard JSON can embed queries, URLs and variables, so the post recommends reviewing changes in version control for queries aimed at unexpected tables or services. Dashboard variables in particular can let a user shape a query in ways its author did not intend; parameterization should go only through supported template variables backed by a server-side data source policy.

On transport hygiene: run Grafana under a service account with a small network role, use TLS for data source connections and validate destination certificates, scope any custom certificate authority trust to the intended connection, and never disable hostname verification to make a dashboard work. Finally, test the failure cases — revoke a user's data source permission and confirm that both the dashboard and an Explore query fail, change the proxy allowlist and confirm a blocked destination cannot be reached, and inspect egress logs for attempted requests rather than only response codes.

Why it matters

The core lesson from the dev.to write-up is that Grafana is a query client as much as a presentation layer, and every configured data source behaves like an authenticated API connection with its own identity, network route and permissions. Organizations that treat dashboards as the security boundary effectively grant every Viewer the reach of the most privileged data source credentials in the organization. There is no patch to install here — the exposure is architectural — so the remedy is configuration discipline: least-privilege service identities, data source permissions matched to trust boundaries, and network egress controls that align what a dashboard shows with what a user can actually retrieve.