Data source security in Grafana: Best practices and what to avoid

Recently, an incorrect security report was published, claiming that there’s a SQL injection attack in Grafana. As we have communicated to the security researcher, this report is wrong. Authenticated users in Grafana have the same permissions as the user configured for the underlying data source. This is not a security issue, but is in fact the intended and documented behavior for authenticated users, and foundational to both Grafana’s “big tent” strategy and the high performance of Grafana.

Since this has been a point of confusion for users, we wanted to create a public resource explaining how credentials and permissions in Grafana interact, and sharing best practices for data source security in Grafana.

How Grafana data sources work

Grafana can visualize data from almost any data store. We achieve this through our “big tent” approach, actively prioritizing interoperability with everyone, even direct competitors. To query data, Grafana’s “data sources” are allowed access to those third-party data stores. As every time when data is being accessed, it’s a good idea to be precisely aware of how things work.

Part of the power and speed of Grafana comes from the fact that the data source builds a data pipeline. Grafana does not require you to copy or store data elsewhere. The initial data storage remains the ultimate source of truth with no risk of data divergence over time. For example, this is why we are seeing so much Business Intelligence uptake: No need to export data into Excel/Google Sheets and have a copy that’s instantly stale.

There are two fundamental ways to access and subsequently display data through Grafana: Anonymous and authenticated access. Anonymous access uses a more locked down and slower data path; this data path is out of scope for this blog post. Authenticated users are split into roughly three groups:

• Viewer: Able to view all data which a specific data source has access to
• Editor: Able to create, edit, and delete panels, dashboards, and data sources for everyone
• Admin: Able to make changes to how the whole instance is being run

You can find more details in our data source permissions documentation.

As more users keep adopting Grafana, we sometimes see confusion about what “Viewer” means. In simple terms: An authenticated Viewer can do everything the data source is configured to allow. Panels and dashboards are shortcuts for convenient access; they do not replace the data source’s controls and permissions. For example, if the SQL user configured for a data source is allowed to SELECT *, DELETE, and DROP, the whole data source and by extension all authenticated Viewers, Editors, and Admins can SELECT *, DELETE, and DROP.

This is the intended and documented behavior for authenticated users, and foundational to both the “big tent” and the high performance of Grafana.

We will walk through more examples and current best practices in the next sections.

A closer look at credentials and permissions in Grafana

Using a web browser’s developer tools, it is trivial for anyone viewing a dashboard to see the raw query sent to the data source, and to construct their own query. If you configure data sources in Grafana, you are responsible for ensuring that the credentials that the data source is configured with only have access to the data you intend viewers to access. 

By default, data sources available in a Grafana instance can be queried by any user who can access that instance. To restrict access to data sources:

• Grafana Enterprise and Grafana Cloud customers can make use of data source permissions and role-based access controls. (Grafana Loki data sources can also use team label-based access controls.)
• Grafana Enterprise and OSS users can use team management.  

However, remember that these features cannot restrict what queries a user with query permission to a data source can actually execute. 

Limiting the credential’s capabilities on the data store’s side

You need to take even more care with data sources with query languages that permit the alteration of data, such as SQL. To help users avoid mistakes here, we include an explicit warning in the configuration page for all SQL data sources.

If you chain a badly configured data source with other weakened security settings, such as allowing anonymous access, it could be disastrous, allowing anyone able to reach your Grafana instance the ability to run something like DROP TABLE users. As a best practice, SQL credentials used for data sources should never have INSERT, UPDATE, or DROP permissions enabled.

We encourage all Grafana Administrators to periodically review the credentials that their data sources are configured with and ensure they are still appropriate. Grafana on-prem administrators should also review the security documentation and the Grafana ini file to ensure their configuration meets their security requirements. 

Limiting allowed queries using Public dashboards

There is one feature that is related: Public dashboards. If you are happy to share your dashboard publicly, the query execution is limited to the exact queries that are in the dashboard. The queries are stored on the server, and the user cannot modify them.

Limiting query exploration in Grafana Explore

Grafana has a central place to write your own queries to get to know your data stores; it’s called Explore. By design, any query that the data source’s credentials allow, is also allowed to be sent. Check the documentation on how to limit access to Explore. If you know that quickly iterating on your queries is not part of any of your workflows, you can also completely disable Explore in Grafana’s config file.

Further questions

Grafana Labs customers who have any questions on this topic should open a support ticket. 

Community users can reach out in the Grafana Community Forum. 

Reporting security issues

If you think you have found a security vulnerability, please go to our Report a security issue page to learn how to send a security report.

Grafana Labs will send you a response indicating the next steps in handling your report. After the initial reply to your report, the security team will keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance.

Important: We ask you to not disclose the vulnerability before it has been fixed and announced, unless you received a response from the Grafana Labs security team that you can do so.

Security announcements

We maintain a security category on our blog where we will always post a summary, remediation, and mitigation details for any patch containing security fixes. You can also subscribe to our RSS feed.