Replies: 6 comments
-
Hey @ppolewicz, Thank you for writing this up. If your users only need to be able to view dashboards, would the public dashboards feature be helpful? We're still exploring how to properly support template variables, but the issue of users executing arbitrary queries is gone (for public dashboards). If public dashboards won't help, could you explain your use case a bit more? The good news is if we or you were to implement a "view-only" mode, public dashboards has already laid some of the groundwork for this.
Sorry this discussion went unanswered for so long. Happy to answer any questions you may have about the work we're doing around public dashboards and how it could support this use case in the future 😄 |
Beta Was this translation helpful? Give feedback.
-
Hey Owen my usecase: A small software house has ~10 projects and ~6 clients. Some clients have one project, some have a few of them. There is also a group of developers from the software house and they have access to everything. Now, client A should be able to view dashboards for just those projects that he's assigned to and not view any data that belong to client B (in fact he shouldn't be able to tell whether any other clients exist). Dashboards contain parameters essential to consuming them:
the first three paramters limit each other - as you select values, those that are farther down the list are narrowed down. The current public dashboard system has a few limitations which disrupt the use case I'm facing:
Our urls are too predictable - maybe if it was uuid4 that could be considered safe though?
Setting date range, aggregation period or cluster name is essential to viewing the dashboard
We only use library panels. A master dashboard is then cloned, the If we can make the dashboards more private by changing their url in such a way that it's impossible to guess, that'd take care of security well enough for my case. I'm happy to hear that some groundwork has been laid down to make this possible during the implementation of public dashboards. I think those would greatly benefit from being able to use library panels and server-validated template variables, right? This does not seem to be a requirement isolated to just the private-but-secure dashboard view. Now, I understand grafana core team may not consider this to be a priority - but it seems that you are going to attack the Library panel part of the problem soon. When do you think this might happen? As for adjusting the template variable system so that it can be safely used - that seems to be the only part that is not already addressed and is not being addressed already. In that case, would it be ok for me or someone from my team to take a stab at it? We'd dig into the code, see where we think the changes should be made, confirm the correct design here and then move onto implementation, documentation and tests. Is that the correct way to contribute? |
Beta Was this translation helpful? Give feedback.
-
Hi @ppolewicz I'm the tech lead for public dashboards. This sounds like a good use case for "default template variable" support, which is next up on our roadmap. To address a couple of points you mentioned:
For template variables we are looking at essentially 3 phases for implementation:
We would love to collaborate on implementation. Can you tell us which data sources you're currently using along with some examples of template variables you have? |
Beta Was this translation helpful? Give feedback.
-
Hey, it's good to hear all this. Things seem to be moving in the right direction. As for data sources, we use a single Prometheus instance. The variables we use are in the bullet point list in my previous comment - period is the thing we put in square brackets when running PromQL queries. Does that help, or should I provide more information? I don't understand the time frame question. I've been trying to move this forward since November 2021, I think. Default variables (2) have an easy workaround - you can change the type of the variable to a constant, then the validator (3) will raise a 400 Bad request if the user fails to submit the only correct value. (4) seems optional / nice-to-have due to uuid4 url |
Beta Was this translation helpful? Give feedback.
-
Hi, I also want to add my use case here because I'm looking forward to this feature. To reduce deployment efforts I only wanna provide one dashboard to our clients and based on the user.login filter the data they can see. For that I have a look up table in the data source and the variables and the where clause working fine based on this. I think a comparison of the query results of each variable with the URL passed variables would be sufficient to enhance security? |
Beta Was this translation helpful? Give feedback.
-
Hello, as you may have heard, we are transitioning away from using discussions to discuss feature requests. We are migrating this discussion to an issue and closing the discussion. The issue is #82950. Feel free to continue the discussion around this there. Thank you! |
Beta Was this translation helpful? Give feedback.
-
What would you like to be added
There is a pair of issues that are impractical to be discussed separately:
The addition would be some kind of an OPTIONAL setting that would allow to use Grafana in a "really read only" mode, where only the queries written by the Dashboard designer can be executed by the user and only with parameters allowed by the Dashboard designer.
Why is this needed (describe your use case and goals)
For some installations it is impractical to separate the data into different databases for different users and being able to restrict who sees what is desired. There might be, I guess, a ton of issues related to the user being able to interact with a database directly. Those might not be officially classified as security today because the security model considers the Viewer user to be authorized to make any query to the database and but I don't want my service to be DoSed by a kid.
How?
The basic design is described here, @torkelo confirmed that it is possible to implement it, though some restrictions might apply. That's fair and fine - depending on a setting, enhanced security might provide a more rigid structure in which not everything can be as easily achieveable as with the open model. We do expect that a dashboard with parameters filled with timeseries will work fine though.
A more detailed plan is provided here. It looks like the code needs to be modified in four places, though some of those are as simple as adding a config flag, or an
if
statement doing basic input validation (checking membership in a list etc).Alternatives
Instead of a config flag, something else could be used - permission level lower than the current Viewer, "Basic" or something like that. Users with that level of access would have their inputs validated and would not be permitted to query the database directly, only via the new "queryless" endpoint. In fact I like that model more and perhaps eventually we should move towards it, but initially I'd like the new behavior to be hidden behind a global config option so that early adopters can report any issues before the feature is visible for everyone. I guess the flag could enable setting "Basic" as the user access level, to reduce the scope of the migration later on.
The details on how to expose it to the users are not firm, bu the core of the idea is simple.
Who
I would implement it with a couple of friends also bothered / impacted by this issue. What we are asking for today is a design review and preliminary approval of the implementation plan from core grafana developers, then code review and merging when we finish the implementation.
Beta Was this translation helpful? Give feedback.
All reactions