Permissions reference
The five Databaas permissions, what each one unlocks, what it implies, and where each is enforced.
The five permissions below are the whole feature-permission model: deployment-wide, with no per-pipeline or per-dashboard variant, and none of them grants access to data.
The five permissions
| Permission | Capability | Area | What it unlocks | Implies |
|---|---|---|---|---|
| View pipelines | can_view_pipelines | Pipelines | See every pipeline, its runs, logs and code. | — |
| Run pipelines | can_run_pipelines | Pipelines | Trigger, clear, mark and pause every pipeline. | View pipelines |
| Use dashboards | can_use_dashboards | Dashboards | Open Superset, SQL Lab included. | — |
| Use notebooks | can_use_notebooks | Notebooks | Open Jupyter. | — |
| Administer platform | can_admin | Administration | The whole Administration group in the sidebar — Access control and Identity — plus Airflow’s connections, variables and pools, and deleting pipelines. | All four of the above |
You hold a permission by direct grant, through a role you are in, or because a permission you hold implies it. Features check the capability in the second column, not the name — so an implied permission works exactly like a granted one.
The cascades
- Run pipelines implies View pipelines. An operator does not need both.
- Administer platform implies everything. An administrator does not need any other permission.
There is no deny: a grant only ever adds, so granting something a person already gets another way changes nothing. Taking access away means removing the grant that actually confers it.
Where each permission is enforced
Every feature checks for itself, on the same shared answer. Hiding a feature from the portal navigation is not the boundary.
| Where | What is checked | When | Notes |
|---|---|---|---|
| Portal navigation and Overview | All five | Every page load | Features you cannot open are not listed. The Administration group appears only for Administer platform. |
| Portal Access control screens | Administer platform | Every request | Otherwise the screen says “Not authorized”. |
| Portal Identity link | Administer platform | Every page load | Listing only; Identity then applies its own administrator rules. |
| Portal Data Catalog | Nothing | — | Deliberately ungated: its contents are already per user. |
| Pipelines — reading a pipeline, its runs, logs and code | View pipelines | Every request | Fleet-wide. |
| Pipelines — trigger, clear, mark, pause | Run pipelines | Every request | |
| Pipelines — deleting a pipeline | Administer platform | Every request | Deleting removes its history irrecoverably. |
| Pipelines — Connections, Variables, Pools, Config, Backfills | Administer platform | Every request | |
| Dashboards (Superset) | Use dashboards | Every access check | A door, not a filter — see below. |
| Notebooks (JupyterHub) | Use notebooks | At sign-in only | Login is the only boundary it offers. |
| Data, in any engine | None of these | Every query | Decided by the catalog, as the signed-in user. |
Notebooks are checked at sign-in. A grant applies the next time you sign in to Notebooks; a revoke does not stop a notebook server already running.
Superset is a door, not a filter. Everyone who can open it holds the same role there and sees the same datasets, charts and dashboards. What differs between two people is which queries return rows — decided by data permissions, not by anything on this page.
What these permissions do not control
- Which pipelines you see. Fleet-wide: if you can open Pipelines, you see every pipeline in the deployment, its runs, code and task logs — including logs from pipelines touching data you have no grant on.
- Which dashboards, charts or datasets you see. Everyone who gets into Superset sees the same list.
- Which data you can read. Granted per warehouse, namespace and table in the Data Catalog and enforced on every query. See data permissions.
Roles
A role is a named bundle of these five permissions with people assigned to it — the only grouping
construct in this model, and it groups people for feature permissions only. Being in a role called
analyst grants nothing in the catalog.
- A role’s permissions are edited on the Roles tab; its membership per person on the Permissions tab.
- A role cannot contain another role.
- The name is the identifier: lowercase letters, digits,
-and_, starting with a letter or digit. - Deleting a role removes its grants too, so recreating one with the same name does not restore access.
See managing access for the screens.