[
https://issues.apache.org/jira/browse/AIRFLOW-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joy Gao updated AIRFLOW-85:
---------------------------
Description:
Airflow currently provides only an {{/admin}} UI interface for the webapp. This
UI provides three distinct roles:
* Admin
* Data profiler
* None
In addition, Airflow currently provides the ability to log in, either via a
secure proxy front-end, or via LDAP/Kerberos, within the webapp.
We run Airflow with LDAP authentication enabled. This helps us control access
to the UI. However, there is insufficient granularity within the UI. We would
like to be able to grant users the ability to:
# View their DAGs, but no one else's.
# Control their DAGs, but no one else's.
This is not possible right now. You can take away the ability to access the
connections and data profiling tabs, but users can still see all DAGs, as well
as control the state of the DB by clearing any DAG status, etc.
(From Airflow-1443)
The authentication capabilities in the [RBAC design proposal
|[https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+RBAC+proposal]]
introduces a significant amount of work that is otherwise already built-in in
existing frameworks.
Per [community
discussion|https://www.mail-archive.com/[email protected]/msg02946.html],
Flask-AppBuilder (FAB) is the best fit for Airflow as a foundation to
implementing RBAC. This will support integration with different authentication
backends out-of-the-box, and generate permissions for views and ORM models that
will simplify view-level and dag-level access control.
This implies modifying the current flask views, and deprecating the current
Flask-Admin in favor of FAB's crud.
was:
Airflow currently provides only an {{/admin}} UI interface for the webapp. This
UI provides three distinct roles:
* Admin
* Data profiler
* None
In addition, Airflow currently provides the ability to log in, either via a
secure proxy front-end, or via LDAP/Kerberos, within the webapp.
We run Airflow with LDAP authentication enabled. This helps us control access
to the UI. However, there is insufficient granularity within the UI. We would
like to be able to grant users the ability to:
# View their DAGs, but no one else's.
# Control their DAGs, but no one else's.
This is not possible right now. You can take away the ability to access the
connections and data profiling tabs, but users can still see all DAGs, as well
as control the state of the DB by clearing any DAG status, etc.
>From Airflow-1443:
The authentication capabilities in the RBAC design proposal introduces a
significant amount of work that is otherwise already built-in in existing
frameworks.
Per community discussion, Flask-AppBuilder (FAB) is the best fit for Airflow as
a foundation to implementing RBAC. This will support integration with different
authentication backends out-of-the-box, and generate permissions for views and
ORM models that will simplify view-level and dag-level access control.
This implies modifying the current flask views, and deprecating the current
Flask-Admin in favor of FAB's crud.
> Create DAGs UI
> --------------
>
> Key: AIRFLOW-85
> URL: https://issues.apache.org/jira/browse/AIRFLOW-85
> Project: Apache Airflow
> Issue Type: Bug
> Components: security, ui
> Reporter: Chris Riccomini
> Assignee: Joy Gao
> Priority: Major
>
> Airflow currently provides only an {{/admin}} UI interface for the webapp.
> This UI provides three distinct roles:
> * Admin
> * Data profiler
> * None
> In addition, Airflow currently provides the ability to log in, either via a
> secure proxy front-end, or via LDAP/Kerberos, within the webapp.
> We run Airflow with LDAP authentication enabled. This helps us control access
> to the UI. However, there is insufficient granularity within the UI. We would
> like to be able to grant users the ability to:
> # View their DAGs, but no one else's.
> # Control their DAGs, but no one else's.
> This is not possible right now. You can take away the ability to access the
> connections and data profiling tabs, but users can still see all DAGs, as
> well as control the state of the DB by clearing any DAG status, etc.
>
> (From Airflow-1443)
> The authentication capabilities in the [RBAC design proposal
> |[https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+RBAC+proposal]]
> introduces a significant amount of work that is otherwise already built-in in
> existing frameworks.
> Per [community
> discussion|https://www.mail-archive.com/[email protected]/msg02946.html],
> Flask-AppBuilder (FAB) is the best fit for Airflow as a foundation to
> implementing RBAC. This will support integration with different
> authentication backends out-of-the-box, and generate permissions for views
> and ORM models that will simplify view-level and dag-level access control.
> This implies modifying the current flask views, and deprecating the current
> Flask-Admin in favor of FAB's crud.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
