Managing Dashboard "Allowed Roles" via GitOps: Preventing UI-Driven Drift with RBAC in Superset

[ferjanin]

Hi Superset Community 👋,

We’re working on managing dashboard access permissions externally via GitOps and the Superset API, using the DASHBOARD_RBAC = True feature flag. Our goal is to make our automation the single source of truth for which roles are assigned to a dashboard’s “Allowed Roles” list.

A key challenge we’re trying to address is preventing manual drift — where a dashboard owner might go into the Superset UI and manually edit the “Allowed Roles” on a dashboard, potentially overriding or conflicting with what our GitOps automation has set.

Our main questions are:

🔎 Is there a fine-grained permission in Superset’s RBAC that specifically controls the ability to modify the "Allowed Roles" field in the UI?

• For example, could we grant a “Dashboard Owner” role can_write on dashboards (for content editing) but deny them the ability to edit the roles attribute of the dashboard?

We’ve looked at the standard permissions but haven’t found one this specific. Is this achievable with existing PVMs, or would it require a custom security manager or code modification?

👉 If such a fine-grained permission doesn’t exist, what are the community’s recommended best practices for mitigating UI-driven drift when managing dashboard access externally?

Our Superset version is 4.1.2.

We want dashboard owners to be able to manage the content of their dashboards freely but ensure the access control (i.e. which roles can see the dashboard) is strictly governed by our GitOps workflow.

Any insights, experiences, or pointers to relevant documentation or discussions would be greatly appreciated!

Thanks!