This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Skip to end of metadata
Go to start of metadata

Work in progress. Feedback welcome.

Introduction

JIRA:  AIRFLOW-85 - Getting issue details... STATUS

Several Airflow users have a need for more rigorous security in Airflow. Part of this involves authentication (authn) and authorization (authz) in Airflow's UI. The current security problems with Airflow's UI are:

  1. Everything is under /admin
  2. There is very limited authorization functionality
  3. There is no auditing about who is triggering an action via the UI
    It looks like airflow.www.utils contains an annotation method called action_logging, which logs actions!

The goal of this document is to address these issues.

Design

UI

The idea is to add a new endpoint called /dags, which is parallel to the /admin UI. This UI will use the same template as the existing DAGs UI in /admin. It will not, however, have any other tabs (Data Profiling, Browse, Admin).

We will need to lock down several pages in the Airflow view class. The pages that are exposed would be:

  • /admin
  • /admin/airflow/refresh
  • /admin/airflow/tree
  • /admin/airflow/graph
  • /admin/airflow/duration
  • /admin/airflow/landing_times
  • /admin/airflow/gantt
  • /admin/airflow/code
  • /admin/airflow/task
  • /admin/airflow/rendered
  • /admin/airflow/log
  • /admin/airflow/run
  • /admin/airflow/xcom
  • /admin/airflow/clear

And perhaps a couple others that I'm missing. The point is that we'd limit the access in the /dags view pretty severely. We'll create a /dags route with: /dags, /dags/refresh, /dags/tree, etc.

Roles

We will introduce three levels of access:

  • dag_viewer: Can see everything associated with a given DAG.
  • dag_editor: Can edit the status of tasks in a DAG.
  • dag_executor: Can click the 'Run' button on a task to have it triggered immediately. Only works for CeleryExecutor.

Groups

We will add the concept of groups. Users can be a member of a group. Both groups and members can be assigned DAG access permissions.

Implementation

Airflow already uses Flask-Login, so we can use this as the login mechanism. Airflow already has LDAP and Kerberos backends (as well as a GitHub backend).

We will need to:

  1. Add the three Flask-Principal needs that map to the roles above
  2. Hook Flask-Principal up to Flask-Login by sending proper signals
  3. Update views to adhere to Flask-Principal permissions

We might want to extend the Airflow view so that we can add Flask-Principal annotations without affecting the underlying Airflow view (to remain backwards compatible for the time being). I'm not sure how feasible this is yet. Given that none of the above routes are locked down, other than @login_required, I believe it should work.

TODO it's unclear to me exactly how groups should be implemented. Should user:group mapping be done in the backend (LDAP, Kerberos, etc), or inside Airflow? My preference is in the backend.
  • No labels