jhtimmins opened a new issue #10469:
URL: https://github.com/apache/airflow/issues/10469
## Rationale
Airflow currently has 185 permissions (where 1 permission is a combo of
Class + Action). The design of the permissions is inconsistent, making them
difficult to modify or organize into roles. This is especially problematic for
the stable API. Because the UI permissions are named after the UI view and
methods, and are intended to control access to the UI view rather than the
underlying resource, they don't map cleanly to API methods.
We need to define a set of permissions that control access to underlying
resources, independent from the interface used to access those resources.
### Aside about names
Flask AppBuilder names permissions in a confusing manner. It uses the term
"permission" to refer to both an action (for example, "can_edit") and an action
+ resource pair ("can_edit on the TaskInstanceModelView"). This document refers
to a `permission` as a unique combination of `action` + `domain`, where
`domain` is the entity to which access is granted. For old permission design,
the domain is the UI view class. For new permission design, the domain refers
to the resource model.
**Description**
There are multiple types of permissions. We should consider each in turn.
* **Variants of create/read/edit/delete for Airflow modelViews** - (ex.
`domain: RoleModelView, permission: can_show`) - Consolidate into `can_create`,
`can_read`, `can_edit`, and `can_delete` for the `Role` resource.
* **Menu access for Airflow modelViews** - (ex. `domain: Task Instances,
permission: menu_access`) - We should do away with menu-specific permissions.
If a user has read access for the resource, they should have menu access in the
UI.
* **Muldelete for Airflow modelViews** - (ex. `domain: PoolModelView,
permission: muldelete`) - I propose combining `muldelete` and `delete` into a
single `delete` action. If you can delete one, you can delete multiple.
* **List for Airflow modelViews** - (ex. `domain: PoolModelView, permission:
can_list`) - Same as `muldelete`. I propose combining `list` and `read` into a
single `read` permission.
* **Default FAB permissions** - (ex. `domain: ResetPasswordView, permission:
can_this_form_post`) - I propose leaving these in place. We technically could
change these to match the new pattern by subclassing the default FAB views and
settings custom permission mappings. If we choose to do that, it should be part
of a separate issue.
* **Edit/read for DAGs** - (ex. `domain: example_branch_dop_operator_v3,
permission: can_dag_read`) - Change to `can_edit` and `can_read` for the same
`example_branch_dop_operator_v3` domain.
* **Airflow view permissions** - The following is a list of examples,
mapping existing permissions to proposed new ones. Where possible, this
involves mapping the view permission to `model.can_read`, or one of the other
CRUD actions.
> * Airflow.can_redirect_to_external_log => TaskInstance.can_read
> * Airflow.can_delete => Dag.can_delete
> * Airflow.can_task => Task.can_read
> * Airflow.can_trigger => Dag.can_trigger
> * Airflow.can_dag_details => Dag.can_read
> * Airflow.can_clear => TaskInstance.can_delete
> * Airflow.can_refresh_all => Dag.can_read
> * Airflow.can_extra_links => Dag.can_edit
> * Airflow.can_index => Seems unnecessary?
> * Airflow.can_refresh => Dag.can_read
> * Airflow.can_xcom => XCom.can_read
> * Airflow.can_rendered => TaskInstance.can_read
> * Airflow.can_blocked => Dag.can_read (does this modify anything?)
**Additional considerations**
There are two motivations.
1. Make view permissions fit for API endpoints.
2. Simplify permissions to make them more usable.
Ultimately, there are two key questions for this issue:
1. Are these permission updates the right changes to make.
2. If they're the right ones, is now the right time to make them?
**Related Issues**
#8112
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
