I’m considering using MySQL as a data source in Grafana and have some concerns regarding the security aspects of executing business data query scripts within a panel, triggered by HTTP requests to the backend data source. Based on the frontend’s potential for tampering, I’ve identified a couple of key security risks:
If the database user account is not restricted to specific tables, it might be possible for a user to modify the data script to query other tables, accessing unauthorized data.
If username filters are used to restrict data access, these conditions can be tampered with, potentially leading to data privilege escalation.
It seems that using relational databases like MySQL as data sources for reporting in Grafana introduces several security vulnerabilities. How can these risks be mitigated? What are the best practices to secure data queries in this context?
seems that using relational databases like MySQL as data sources for reporting in product X introduces several security vulnerabilities
the onus is on your db admin to configure security based on mysql best practices. it is not a grafana issue but more of security hardening issue on your mysql part.
for ex
dont give perms to specific accounts but security groups
use an actual service account to access mysql by adding it to security group
this sec group should have read only perms
use stored procedures with exec perms only given to security group
Regardless, the fact that Grafana panels support SQL script queries and pass them unencrypted to the backend for execution makes Grafana insecure.
This is a serious security flaw. This issue becomes apparent when you expect different users under Grafana to see different data filtered from the same relational database.
Actually, to fix this, Grafana could encrypt the Panel query SQL script using the login user’s token, and then decrypt it in the backend for execution. This would solve the problem.
I would say this approach won’t fix it. What is stopping me to edit SQL query in the browser - your approach will just encrypt that modified SQL and backend will decrypt and execute it.
Could you show me any Grafana competitor, which has this “security issue” solved (and any doc how it is sorted), pls?
Using global variables, such as login user association, for data isolation is ineffective. It has been verified that users can delete SQL filtering conditions and modify SQL scripts.
Therefore, the fundamental solution is: in viewer mode,
Solution 1, SQL should not be passed to the frontend. The interaction between frontend and backend should only involve a collection of variables and values.
Solution 2, SQL encryption verification, compare the SQL that is sent back with the original one that was sent out.
Sorry, I asked for competitors. What I know no competitor has implemented that.
That’s because they are not designed for this.
If you need it, then build own “Grafana” and you will very likely discover how complex problem is it if you want to implement it properly and not only small subset of features. I also see problems with UX and with security with your proposed solutions.
Search forum and you will find that this “problem” is reported many times - it is not a security issue, but design. It is mentioned in the doc: MySQL data source | Grafana documentation
Database User Permissions (Important!)
The database user you specify when you add the data source should only be granted SELECT permissions on the specified database and tables you want to query. Grafana does not validate that the query is safe. The query could include any SQL statement. For example, statements like USE otherdb; and DROP TABLE user; would be executed. To protect against this we Highly recommend you create a specific mysql user with restricted permissions.
Using Grafana with RDS like MySQL as data sources is not safe.
It not only fails to ensure data filtering based on login users, but users can also modify SQL scripts transmitted via the browser’s web interface.
Under such conditions, users can delete data tables from authorized data sources and excetion other DDL operations.
Therefore, we should be cautious when using RDS as a data source for Grafana.
