Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete redo of permissions in Redash #3284

Open
arikfr opened this issue Jan 15, 2019 · 18 comments
Open

Complete redo of permissions in Redash #3284

arikfr opened this issue Jan 15, 2019 · 18 comments
Labels

Comments

@arikfr
Copy link
Member

@arikfr arikfr commented Jan 15, 2019

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:

  • You want to share high level revenues KPIs dashboard with everyone, but give access to the raw data only to a limited group of people.
  • You want to share a few dashboards with your investors without giving them access to all your data.

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:

  1. Add support for "feature detection", to allow for the application to decide whether a specific object can be shared or not. We will start with disabling current sharing options (embed/shared link) when the object uses parameters.
  2. Add support for safe execution of parameters: #2904
  3. Add query results API that is referenced through the query itself.
  4. Add support for sharing queries/dashboards with other users, through the current permissions dialog.
  5. Add support for a public link/access to an object, which will replace the current share/embed features in queries/dashboards.
  6. Add an API to create shareable links for objects with some parameters predefined (to allow Embedded Analytics use cases).

Some things to consider:

  • What happens with an object that was shared already when you add a parameter?
  • Add a concept of workspaces/teams instead of groups? So anything you create in this workspace has some default permissions? Relevant: #2397.
  • Until now you had to create data sources of type Query Results, URL, CSV, etc for to purpose of managing permissions. But once we have permissions decoupled from data sources, we can have all these data source types as built in types, so you can use them to load data into Redash and then decide who you share it with. (related discussion)
  • #1909 is somewhat related here.
@ice2038

This comment has been minimized.

Copy link

@ice2038 ice2038 commented Jan 15, 2019

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.

@pachecobruno

This comment has been minimized.

Copy link

@pachecobruno pachecobruno commented Jan 16, 2019

Great! Today I need to publish some results/insights for specific users, who should not access the queries or data sources. Will it be possible to create groups with more restrictive permissions? What you think about granularities of roles / permissions? Tks!

@ice2038

This comment has been minimized.

Copy link

@ice2038 ice2038 commented Jan 17, 2019

Version 1.
Access_Version_1

@arikfr

This comment has been minimized.

Copy link
Member Author

@arikfr arikfr commented Jan 20, 2019

Thanks, @ice2038. I'm planning to do a deeper dive into the planning of this in the coming days, and I will take into account your suggestion. I will post here follow ups.

@pachecobruno if I understand your use cases correctly, they will be addressed by the work on this.

@rredkovich

This comment has been minimized.

Copy link

@rredkovich rredkovich commented Feb 6, 2019

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:
https://redash-stage.mrshoebox.com/embed/query/5/visualization/10?api_key=9kVjy030spYDgL1Eh77f1ckfr2h0TSK2FR1FF3wh

@rauchy

This comment has been minimized.

Copy link
Contributor

@rauchy rauchy commented Feb 6, 2019

@rredkovich this is something we're working on at the moment (have a look at the parameter safety PRs) so we hope it won't be too long before you could share visualizations with parameters.

@rauchy rauchy mentioned this issue Feb 26, 2019
1 of 1 task complete
@rauchy rauchy mentioned this issue Apr 6, 2019
1 of 1 task complete
@morsedl

This comment has been minimized.

Copy link

@morsedl morsedl commented May 10, 2019

+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.

Both have online editors (OPA, Casbin) where one can explore how policies are written and operate.

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.

@justinclift

This comment has been minimized.

Copy link
Contributor

@justinclift justinclift commented Jul 3, 2019

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.

@hsluoyz

This comment has been minimized.

Copy link

@hsluoyz hsluoyz commented Jul 3, 2019

Hi, I'm the author of Casbin. You can consider using Casbin, as it supports 8 languages, including Python, Go and Javascript (Node.js). It supports RBAC with domains/tenants model (can be used to build a AWS cloud or GitHub).

As for PyCasbin (Python's implementation), it supports storing policy rules into databases via SQLAlchemy or Peewee, see the adapters. You don't need to handle the storage manually.

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 :)

@piperck

This comment has been minimized.

Copy link

@piperck piperck commented Jul 17, 2019

I want to know this issue processing. Anyone know?

@gseva

This comment has been minimized.

Copy link
Contributor

@gseva gseva commented Aug 13, 2019

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.

@lsmoker

This comment has been minimized.

Copy link

@lsmoker lsmoker commented Oct 30, 2019

What's the status of this issue? I'm waiting to implement redash for our organization but need this enhancement (similar to what @ice2038 proposed) first.

@simzen85

This comment has been minimized.

Copy link

@simzen85 simzen85 commented Nov 19, 2019

+1

@daniellangnet

This comment has been minimized.

Copy link

@daniellangnet daniellangnet commented Jan 2, 2020

This would be hugely valuable. Even just simple dashboard-level permissions would help a ton so that certain dashboards can be restricted to certain groups of users.

@qmgeng

This comment has been minimized.

Copy link

@qmgeng qmgeng commented Jan 7, 2020

+1

1 similar comment
@Vitorjardim

This comment has been minimized.

Copy link

@Vitorjardim Vitorjardim commented Jan 7, 2020

+1

@gilbzs

This comment has been minimized.

Copy link

@gilbzs gilbzs commented Jan 20, 2020

@arikfr Any update with the progress of this issue? We're looking forward to the new & improved Redash user access controls / permissions.

@TimothyZhang

This comment has been minimized.

Copy link

@TimothyZhang TimothyZhang commented Feb 11, 2020

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.