How Apache Superset dashboard access control works and when to configure it
In a shared Apache Superset dashboard access control setup, who sees a dashboard depends on three things that interact: dataset permissions, dashboard role access and the publication state of the dashboard. A user who can open a dashboard still needs data access to every dataset its charts query, and a dashboard that is published or shared can expose charts built on datasets the viewer was never meant to reach. Start by mapping which teams own which datasets, because that ownership decides whether dataset-level permissions alone are enough or whether you need the dashboard-level controls described below.
Enable DASHBOARD_RBAC when several teams share one dataset but must see different dashboards. Without it, anyone with access to a dataset can usually reach every dashboard built on it, so dataset grants become the only boundary. With the feature turned on, you assign roles to each dashboard in its properties, which lets two groups use the same underlying data while seeing different views. Confirm the flag name and its behavior in the configuration documentation for your Superset version, since the access model is changing across releases. This page covers the decision and its trade-offs, not a general overview of Superset.
Plan for the publication state before you rely on roles. Draft dashboards are visible to their owners and to people they share with, while published dashboards are the ones users browse to, so a dashboard that is published with the wrong roles is the most common leak path. Decide who can publish, who reviews dashboards that touch sensitive datasets, and how you will test a viewer account against each dashboard before go-live. Ask your team to confirm the exact permissions that govern publishing and dashboard ownership in the version you run, because these vary between releases.
Dataset access, dashboard roles and publication options compared
This table compares dataset permissions, DASHBOARD_RBAC dashboard roles, draft versus published status and row level security by what each one controls, what it leaves open and when it fits. Read each row as a separate layer, because a user must pass the checks for every object a dashboard touches. Confirm the exact DASHBOARD_RBAC behavior for your Superset version in the configuration documentation before you rely on it.
| Option | What it controls | What it does not control | When it fits |
|---|---|---|---|
| Dataset permissions | Which users can query or open charts built on a given dataset through their assigned roles | Dashboards that other users can see, which may still expose data from shared datasets | Data that must be restricted to specific teams regardless of which dashboard displays it |
| DASHBOARD_RBAC dashboard roles | Which roles can view or edit a specific dashboard, so visibility can follow the dashboard rather than the dataset | Access to the underlying datasets, so a viewer may still be blocked by dataset rules or may see data through charts on other dashboards | Shared datasets where different audiences need different dashboards, after you confirm the flag's behavior in your version |
| Draft versus published status | Whether a dashboard is visible in its published state or still being edited, which affects what casual viewers find | Permissions for anyone who already has access to the dashboard or its datasets, and it is not an access control on its own | Hiding unfinished work from broad audiences during development and review |
| Row level security (RLS) | Filters that limit the rows returned for a dataset based on rules applied to the querying user or role | Column-level exposure, export of results a user is allowed to see, or data reached through other unfiltered datasets | Per-customer, per-region or per-business-unit restrictions on a shared table |
| Shared datasets across dashboards | Reuse of one dataset definition in many dashboards and charts | Any dashboard-level restriction, because a dataset that one dashboard exposes can be reached through another | Only when the owner has mapped every dashboard and chart that uses the dataset |
| Export and download permissions | Whether a user can export chart or dashboard data once they can view it | Whether they can see the data in the first place | Sensitive datasets where viewing is allowed but copying is not |
Choosing the access model for your dashboard population
Illustrative: a finance team of ten analysts works from one curated reporting table in a single warehouse schema. At this size, dataset-based access is usually enough. Grant the team's role access to that one dataset and nothing else, so the boundary sits where the data sits. Dashboards then inherit what a viewer can query.
- Grant the dataset, not the database: attach the one dataset to the team's role so no other tables in the connection become visible.
- Keep editing with owners: give two or three named builders editing rights and keep most analysts on view-only access.
- Publish deliberately: keep new dashboards in draft until a reviewer has checked the charts and the filters they expose.
- Add dashboard roles only when needed: DASHBOARD_RBAC adds a second place to maintain, so confirm with your Superset version whether you need it at this size.
Check which roles can see the dataset, then sign in as a viewer account and confirm that only the expected dashboards and charts appear.
Illustrative: sales and finance share a warehouse, and some tables feed both teams' dashboards. Here the main risk is not a missing permission but a shared dataset that exposes more than the dashboard it sits under. Build a dataset-based role for each team that lists only that team's datasets, then use DASHBOARD_RBAC where two teams can reach the same dataset but only one should see a particular dashboard.
- Scope roles to team datasets: each team's role lists its own datasets, with schema-level grants used only where the schema is owned by that team.
- Use dashboard roles for shared datasets: where both teams can query a dataset, restrict the dashboard built on it to the owning team. Confirm how your version applies these checks.
- Remember the dataset is the boundary: anyone with access to a dataset can build a new chart on it, so hiding a dashboard does not hide the data.
- Avoid all_database_access: this grant exposes every dataset on the connection to the role that holds it.
Review each shared dataset once a quarter and list which teams can query it. Record the owner of every dataset so that a grant request has someone to approve it.
Illustrative: a software vendor embeds a per-customer usage dashboard in its product, and a second team publishes an open statistics page. These two cases should not share the internal role model. Embedded dashboards are usually governed by guest tokens that the host application issues for each viewer, scoped to that viewer's data. Public dashboards need no login at all, so they fit only data that anyone may read.
- Use guest tokens for customers: the host application issues a token per viewer, and the token should carry only the filters that viewer may see.
- Reserve public dashboards for public data: anyone with the link can open a published public dashboard, with no account required.
- Separate tenant data in the dataset: use row level security or tenant-specific datasets, and test each one as a separate control.
- Avoid shared internal viewer accounts: a single account used to render embedded content makes it hard to trace which viewer saw what.
Before launch, request a token for one tenant and confirm that no rows from another tenant appear, including in the filter drop-downs.
Illustrative: a bank keeps customer-level records and aggregate risk figures in the same database. Access decisions here should be made in layers. Use a separate database connection for each sensitivity tier, with a warehouse account limited to that tier, so the connection itself sets the outer limit. Inside each connection, grant datasets by role, then use dashboard roles and export controls as additional layers. Auditors will look for evidence of each layer, so document the design alongside the configuration.
- Split connections by sensitivity: one Superset connection per tier, each backed by a warehouse account that can read only that tier.
- Classify each dataset: record the sensitivity tier, data owner and approver for every dataset, and keep the register current.
- Layer dashboard roles on top: dashboard roles control visibility of dashboards, but the dataset grant still decides what can be queried, so test both.
- Restrict exports and SQL Lab: limit download and SQL access on the sensitive connections to named roles.
Keep role assignments, test results and the classification register together so that a reviewer can trace each user to the datasets they can reach. This page describes the design choices. It does not establish compliance, which an independent assessor must confirm.
How to configure dashboard role access in Superset
This sequence moves from an inventory of who needs which dashboards to a tested setup in which each role sees only the dashboards it should, with draft and published states checked before any user is onboarded. Each step ends with a check you can repeat after future changes.
Inventory audiences, datasets and dashboards
Before touching Superset, list every dashboard and the datasets, databases and schemas each one reads from, then group the dashboards by the audience that should see them, such as finance, operations or a regional team. Mark which dashboards are still drafts and which are ready for viewers. Note any dataset that feeds more than one audience, because that is where leakage through shared datasets usually starts. The output is a single table that maps audiences to dashboards and datasets, reviewed by the data owners who will approve access.
Set DASHBOARD_RBAC in configuration
Enable the DASHBOARD_RBAC feature flag in your superset_config.py, the file that holds your deployment settings, then restart the web and worker processes so the change loads. Confirm the exact flag name and how it is set in the configuration documentation for the Superset version you run, since feature flags can change between releases. Check the result by opening a dashboard's properties as an admin and confirming that the roles field is present and editable. If the field is missing, the flag has not loaded and later steps will not behave as described.
Create roles and assign them to dashboards
Create one role per audience that needs dashboard-level access, using the role editor in the Superset UI or your own management process, and give each role only the view permissions it needs on the dashboards and charts it covers. Then open each dashboard's properties and assign the matching roles. Keep datasets in mind: a role that can open a dashboard still needs access to the underlying datasets for the charts to render, so confirm the dataset permissions in the same pass. Record the dashboard-to-role mapping so it survives future reviews.
Verify the Gamma user view
Create a test user with the Gamma role, assign it to one audience role only, and sign in as that user in a private browser window. The dashboard list should show only the dashboards mapped to that audience, and direct URLs to any other dashboard should be refused. Repeat the check with a second test user in a different audience. The output is a short test log with the user, the role, the dashboards seen and the dashboards refused. Gamma is the built-in role most users should hold, so this is the check that matters most.
Test draft and published states
Confirm how draft and published dashboards behave for each role before you publish anything. Sign in as a test viewer and an editor, then check that a draft dashboard is not visible to viewers, while the editor can open it and make changes. Publish one test dashboard, reload the viewer session, and confirm it appears only where the role mapping allows. Verify the behavior against the documentation for your version, because the published flag and its visibility rules are a separate control from role assignment and should not be assumed to replace it.
Check shared datasets for leakage
Review every dataset used by more than one dashboard and confirm that a viewer who should not see a sensitive dashboard cannot reach its data by another route, such as an ad hoc chart in SQL Lab or Explore built on the same dataset. Restrict the dataset-level permissions or split the dataset if needed, then rerun the Gamma test for each affected role. Record each shared dataset, the roles that can query it and the decision made. This step is where most dashboard-level controls fail, so treat a clean result as the exit condition.
Document the mapping and retest after changes
Store the final dashboard-to-role mapping, the test users and their expected results in your change record, and assign an owner to review it. Repeat the Gamma and draft checks after every new dashboard, every role change and every Superset upgrade, since role and permission behavior can shift between versions. Confirm upgrade steps against the upgrade documentation before you apply them to production. The output is a repeatable test that a reviewer can run without rebuilding the analysis.
How dashboards leak through shared datasets
In Superset, a dashboard is a presentation layer over datasets, so access to the underlying data often decides what a viewer can actually see. The cards below cover the common paths where a dashboard that looks restricted still exposes rows, columns or exports to people who should not have them.
Shared datasets across audiences
A single dataset can feed several dashboards, and anyone with access to that dataset can open it directly in Explore or build new charts on it. Access granted for one audience therefore reaches every chart built on the dataset. Decide per dataset who may query it, and where audiences differ, create a separate dataset with the rows or columns each audience needs. Verify by listing the dashboards and charts that reference each dataset and checking the roles that can open it.
Chart filters that do not restrict rows
A filter on a dashboard changes the query for that view only. The underlying dataset still returns every row to anyone who can query it through Explore, SQL Lab or another chart. Treat dashboard filters as navigation, not as security. Where row visibility must differ by user, apply row level security on the dataset or database side, then test it by logging in as each audience and checking the counts returned.
Saved queries and SQL Lab reuse
Saved queries and SQL Lab results can read the same tables a dashboard uses, sometimes with columns the dashboard hides. A user with SQL Lab access can reproduce any dataset's data without opening the dashboard at all. Review which roles hold SQL Lab access, which databases they can query, and which saved queries are shared with others. Check the query history for a sample account to confirm what it can reach.
Exports from visible charts
Anyone who can see a chart can usually export its data as CSV or Excel, and sometimes download the image. A dashboard restricted to a small group can therefore leave that group with a full extract of the data. Pair dashboard access with export permissions, and confirm that the roles allowed to view a sensitive dashboard are also the only roles allowed to export from it.
Embedded and public dashboards
Public dashboards and embedded dashboards answer requests without a normal login, so the access checks you configured for signed-in users may not apply. Any dataset behind a public or embedded dashboard is visible to whoever holds the link or token. List every published public dashboard and every guest token issuer, then confirm that each one exposes only data approved for outside viewers.
Drafts and unpublished dashboards
A dashboard left in draft or unpublished state can still be reachable by URL by users whose roles include access to its charts and datasets. Owners often assume that unpublished means hidden. Review the dashboard list for each role, search for old drafts that contain sensitive charts, and remove or restrict those that no current audience needs.
Questions teams ask before configuring Superset dashboard access
Can our own team configure dashboard access control in Superset?
Yes, many experienced teams can, because the controls are built into Superset and its Flask-AppBuilder foundation. The work is less about clicking settings and more about deciding who should see what, mapping those decisions to roles, and confirming how the release you run behaves. Your team needs to understand how dataset permissions, dashboard role assignments and the DASHBOARD_RBAC setting interact, since that is where most mistakes happen. The slowest part is usually agreeing the access model with the people who own the data, followed by writing test cases that prove a limited user cannot reach a restricted chart through a shared dataset. A partner adds the most value when the model spans many business units or when an auditor will expect independent test evidence. Plan for regression testing after each upgrade, because access rules can shift between releases.
What drives the cost of a fixed-scope dashboard access design?
The main drivers are the number of distinct audiences, the number of dashboards and datasets in scope, how many identity sources feed Superset roles, and how unclear existing access already is. Work usually falls into discovery workshops, role and dataset mapping, configuration in a staging environment, testing and handover documentation. Most of this is one-time effort. Recurring effort appears when new dashboards are added, when access reviews run, and when upgrades require retesting. Costs rise when owners are slow to decide, when identity groups must be cleaned up before mapping, or when many shared datasets need separate review. Ask any quote to show each phase, who performs it, what evidence is delivered and which changes trigger a change request. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and the quote follows from that written scope.
What must our team provide before access design work starts?
Three inputs matter most. First, a role inventory listing every Superset role in use, including built-in roles and any custom roles, along with who holds each one. Second, a dataset owner register that names the person who approves access to each dataset and the database it comes from. Third, an audience list that maps business groups to the dashboards they need, ideally with the matching group names from your identity provider or directory. A current dashboard list showing which items are published and which are drafts also speeds up the work. Confirm that a sponsor can name approvers and settle disagreements between owners. Without these inputs, the design becomes guesswork, and testing takes longer because the team must rediscover intent during validation.
How long does access testing take for a large dashboard estate?
Testing time grows with the number of dashboards, datasets and distinct audiences, because each combination of user population and object needs a verified outcome. Test cases should cover viewing, exporting, editing and leakage through shared datasets in Explore and SQL Lab. Testers need accounts that represent each real business role, not only administrator accounts, and those accounts must be set up before testing starts. A small estate with few audiences can be tested in a short cycle. A large estate with many shared datasets usually needs full coverage for high-sensitivity dashboards and a sampling method for the rest. Ask any provider to state the sampling approach, the evidence format and the retest rules before you agree a schedule.
Do dashboard access changes require Superset downtime?
Many access changes, such as assigning a user to a role, can be made in the Superset interface without a service outage, but confirm this for your deployment and release. Changes to configuration values, including DASHBOARD_RBAC or role mapping in superset_config.py, require restarting the web and worker processes so they load. Changes that alter role definitions or run during an upgrade need a maintenance window. The upgrade guide asks teams to back up the metadata database, test in staging and check the breaking change notes first. Ask the plan to label each change as online or restart-required and to describe how a rollback works.
Can a user see restricted data through a shared dataset on a dashboard?
Yes, this is possible when access is granted only at the dashboard level while the underlying dataset remains open to the same users. A user who can open that dataset in Explore or SQL Lab may see its rows whether or not they can open the dashboard. Dashboard restriction alone therefore does not protect the underlying data. Dataset permissions and, where needed, row level security must be designed together with dashboard roles. Test with a Gamma account that holds only the intended roles, and check Explore, SQL Lab, chart export and API endpoints, not just the dashboard page. Confirm how DASHBOARD_RBAC interacts with dataset permissions in your release before you rely on it for protection.
Are draft dashboards visible to other users in Superset?
Publish status mainly affects what users see in dashboard listings, so treat drafts as work in progress and never as a protected store. Visibility rules can differ between listings, direct URLs and API calls, so confirm the behavior in your release before you depend on it. A practical publishing step has owners review each chart, confirm which dataset it uses and set roles before the dashboard is published. Sensitive drafts should sit behind a restricted role from the start. Test every draft and published state with a non-owner account, including direct links. Record the result so the owner can see what changed when a dashboard moves from draft to published.
How DeployOpen scopes dashboard access control work
DeployOpen fixes the access design in writing before any Superset configuration changes. The written scope names every user population, the built-in roles each one maps to, which datasets and databases each role may read, and which dashboards need role-based restriction rather than dataset-based access. It also records the decision on DASHBOARD_RBAC, the handling of draft and published dashboards, and the datasets that feed more than one dashboard, since those shared datasets are where leaks usually start. The scope lists the identity provider groups that feed AUTH_ROLES_MAPPING, so the access model is agreed with the people who own those groups before anyone builds it. Confirm with your team which Superset version you run, because role and permission behavior can change between releases and the upgrade notes in UPDATING.md should be checked against the design.
DeployOpen delivers the role and dashboard configuration inside your own Superset deployment, in your environment, against your metadata database and identity provider. The work covers custom roles built on top of the built-in ones, dashboard ownership and role assignments, dataset permissions, and the documented steps for keeping edited roles stable when superset init runs again. Each change is recorded so that your team can reproduce it in staging and in production. Where access depends on row-level filters, those filters are configured and documented alongside the dashboard roles, so a reviewer can see which rule applies to which population. You receive the configuration, a short description of each role, and a list of accounts used for testing.
DeployOpen tests access by signing in as each role and each representative user and checking what that identity can see, export and query. The test plan includes direct URLs to dashboards that the role should not reach, dashboards shared through datasets that appear elsewhere, draft dashboards that a non-owner should not view, and chart and data views that expose the same underlying table. Results are written up with the expected and observed behavior for each case, so that failed cases are fixed and retested rather than accepted. After go-live, changes to roles, identity mappings or dashboards go through a retainer, so access is re-tested after each Superset upgrade or new dashboard. DeployOpen prepares the controls, configuration and test evidence that your auditors or assessors may ask for, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies.
