Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Complete redo of permissions in Redash #3284
This is a first draft to describe this project. We invite interested parties to share their thoughts. As we progress with better planning this, I will update the issue description and add relevant sub issues for the steps.
Up until now, access to data in Redash was governed by access to the data source which the data came from. It made sense as a good default, especially if we want to promote data democracy. However, it introduces many challenges in less trivial use cases, for example:
Today, you can share a single query using the embed link or a whole dashboard using the share link. This is currently limited only to queries/dashboards without parameters, as the latter requires access to run any query on the underlying data source.
The goal of this project is to redo our permissions model and introduce safety to parameters execution, to support sharing a query or dashboard with anyone users choose - internal or external.
This is a huge change in how Redash works and will be implemented in steps:
Some things to consider:
I am interested. I have a problem with access to dashboards for viewing. I would like to have access to such dashboards and to such requests only from the assigned group of users.
I propose to introduce collections which may include dashboards, queries, tags, etc. These collections can be assigned to groups of users who see only them and nothing else.
Hi, do you have any ETA when this fixes an issue visualization with parameters could not be shared #2377 ?
P.S. Just in case here is example of this error https://redash-stage.mrshoebox.com/embed/query/3/visualization/7?api_key=0DgRNn12On9zM4MVkLXmxiAUsQ0tDhnHFlbsjnyl
and same visualization, but parameter value is hard coded in query:
+1 For being able to use query_ and cached_query_ when the underlying query is parameterized.
Also, regarding permissions (aka policy management, authorizations):
I've recently being hunting around to find the best free / open source solutions, with a particular focus on Python implementations, but ones that support multiple langauges, platforms, etc. What I found to be the most promising options were implemented in Go (except one), which I suppose makes sense.
Open Policy Agent seems to be coming into its own and has an impressive list of adopters. Authorizations happen over REST. Policies are written in Rego. OPA is an project supported by the Cloud Native Computing Foundation (CNCF).
Casbin appears to be another good option. Instead of authorizing over REST, Casbin provides an impressive list of SDKs for various languages. It also support numereous policy models right out of the box (numerous variants of ACL, RBAC, plus ABAC, REST routes, Deny-Override, and Priority).
The OPA documentation explains how several of these can be implemented in Rego. My sense is that both systems are flexible and well thought out, with Casbin supporting numerous traditional and well-defined policy models, whereas OPA with Rego seems a bit more focused on providing a language and framework for authoring whatever policy model one wishes. Think Django vs. Pyramid.
ORY Keto is another interesting option, and is a part of the ORY ecosystem. How authorizations take place is still not clear to me, but they only list a REST API for Keto, (whereas they list both REST and SDK options for Hydra, a related component in their ecosystem).
Finally, if one wanted a solution primarly (only?) for Python, ziggurat_foundations is often mentioned and looks quite nice. It provides mixins for SQLAlchemy classes, which I find appealing, and I suspect that makes dealing with policies seem natural, pythonic, and easy.
Perhaps Redash could use one of these, or something similar, to more quickly, flexibly and thoroughly re-implement its permission management. Even if it's decided that implementing from scratch is the preferred option, I think it'd be great if regardless an eye was kept toward either having, or being in a good position, to offer plugins in Redash that could authorize requests against these other solutions as well.
As a data point, it would be useful for Redash to have a simple "This specific dashboard (eg one including salary details) should only be accessible to person A, B, and C".
It's possible to achieve this result (eventually) with the current approach through careful group planning.
But that's a problem when a customer has an extensive set of existing queries that would need re-doing using a different grouping model, just for one (sensitive) dashboard.
It's easy to use, as you can debug your model and policy setting in the online editor before putting into production. It also supports distributed policy enforcement if you need it.
Let me know if you have any questions :)
I really like @ice2038's proposal, it would be very useful in our use case.
It would be also nice for our us to separate edit permissions in query edit and results update permissions, so that a user could refresh existing queries but not changing the underlying code nor creating new ones.