Dashboards RBAC. Is there any plans to share dashboards access to specific users or groups?

[bun4uk]

It would be highly beneficial to implement a flexible access control feature in the Redash, similar to the one in Metabase. This would allow to configure access to different dashboards for specific user groups, providing a more convenient and efficient way to manage dashboard permissions.

[bun4uk]

As I see, there was a PR with this functionality earlier, but it was rejected
#2011

[saturnonfire]

That would be helpful 👍

[DregonX2]

If anyone on the Redash team is willing to work on this and get it done, I would be willing to discuss payment for the work - this feature is essential to my use case. It looks like it was rejected in #2011, but that was years ago. Lets re-examine this please!

[abhijeetbold]

Agree... this would be really helpful, instead of giving access on underlying data sources. This would limit unnecessary access as well.

[yoshiokatsuneo]

I think Dashboard-level access control may requires a new access control model that is bit different from current simple data source based model.
Without good model, adding the feature may makes permission feature complex and can be the cause of miss configuration or bug and the security issue.

So, to implement the feature, I think we need to well-designed access control model and UI that is easy to understand, and consistent through out the product.

And, I think we are welcome contributors who lead the design and implementation.

[yoshiokatsuneo]

For now, I think adding another data source limiting the access may work for some cases.
How about ?

[yoshiokatsuneo]

@abhijeetbold

The only way right now is to give access to entire data source itself which is too wide. If the user needs to see data in the dashboard of a single table.

How about just creating another "Redash data source" ?
For example, you can create multiple Redash data sources for the same MySQL server. Each Redash datasource can have different MySQL users where one MySQL user have permission for full access and another MySQL user have permission to access only one table ?
It might not be the best solution as we need to create different queries for different Data Sources.
But it is somehow working in our organization , and I think it may work for some use cases.

[DregonX2]

@yoshiokatsuneo Your suggestion just pushes access control to somewhere it cannot be in my use case - I need to filter my queries based on a field within the table. I'm in a federated organization, so for example, I would want to display the contents of a table segmented by the result of the 'Member name' field inside the table. The member named John can only see John's data, and the member named Bob can only see Bob's data. I I can't do this using permissions in the database, because I need to give all users access to the field and table in order for them to be able to filter by its content, and in so doing I've already given them access to too much. What I need to do is create a Query that filters only John's data, and another query that filters only Bob's data, then give John access to John's query and Bob access to Bob's. Your suggestion doesn't allow for this.

[yoshiokatsuneo]

@DregonX2

Thank you for your use case.
If the data source is PostgreSQL, you may set low level security policy for each user and create Redash data source for each user.
Or you may create views for each users...
But yes, it depends on the data source, and may not be practical if there are many users...

[DregonX2]

So if I want to hire a developer to add more robust RBAC to Redash for a future release, do you have any advice on how I can help increase the chances that our code is accepted in to the main project? Any advice is appreciated.

[eradman]

The major hurdle is usually code review, but this should be manageable as long as the feature can be developed in a series of commits that separate concerns and are not overly complicated.

[abhinavhuddaflexsin]

Hey everyone, wanted to share an update on this.

We've implemented object-level RBAC in our fork that directly addresses this. The core idea is a new object_permissions table that stores read/update/delete permissions per group per dashboard (and query). This completely decouples dashboard visibility from data source access.

In practice it means an admin can now grant a specific group access to exactly the dashboards they should see — nothing more. Users outside that group get a 404 even if they know the URL. The dashboard list is also filtered server-side so they won't see what they don't have access to.

A few highlights:

Permissions are managed via GET/POST /api/dashboards//permissions
New dashboards default to admin-only until explicitly shared
Backward compatible — existing dashboards without permission records stay accessible as before
All permission changes and denied access attempts are audit logged
The feature is gated behind REDASH_FEATURE_SHOW_PERMISSIONS_CONTROL for the UI and REDASH_FEATURE_DEFAULT_QUERY_ADMIN_ONLY for the default behavior on new objects.

Happy to share more details or the relevant code if useful.
@arikfr