[
https://issues.apache.org/jira/browse/AIRFLOW-5024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ash Berlin-Taylor resolved AIRFLOW-5024.
----------------------------------------
Resolution: Not A Bug
The dag-level access control has not been included in the releases yet - this
feature is only available in the master branch of Airflow.
> RBAC & access_control params
> ----------------------------
>
> Key: AIRFLOW-5024
> URL: https://issues.apache.org/jira/browse/AIRFLOW-5024
> Project: Apache Airflow
> Issue Type: Bug
> Components: webserver
> Affects Versions: 1.10.4
> Reporter: Aneesh Joseph
> Priority: Major
>
> DAG level *access_control* permissions were recently setup with this PR -
> [https://github.com/apache/airflow/pull/4642]
>
> I created a sample role from the RBAC UI with no permissions, The role name
> was *sample_team*.
>
> I created below DAG
>
>
> {code:java}
> from airflow import DAG
> from airflow.operators.bash_operator import BashOperator
> from datetime import datetime, timedelta
> default_args = {
> 'owner': 'sample_team',
> 'depends_on_past': False,
> 'start_date': datetime(2019, 2, 1),
> 'retries': 4,
> 'retry_delay': timedelta(minutes=1),
> }
> dag = DAG('sample-team-my-sample-pipeline', default_args=default_args,
> schedule_interval='15 0 * * *',catchup=True,access_control={'sample_team':
> ['can_dag_edit', 'can_dag_read']})
> t1 = BashOperator(
> task_id='sample_task',
> bash_command="""
> echo {{ execution_date }}
> """,
> retries=1,
> dag=dag)
> {code}
>
> and was expecting that any user who is added to *sample_team* role will now
> have access to this DAG, but that wasn't the case. The user is able to login,
> but can't view the above DAG. I looked at the UI roles back again to see the
> Permissions which were automatically added to the *sample_team* role. Below
> were the Permissions which were auto-added
>
>
> {code:java}
> [menu access on About, can rendered on Airflow, can task stats on Airflow,
> can pickle info on Airflow, can task on Airflow, can refresh on Airflow, can
> index on Airflow, can blocked on Airflow, can log on Airflow, can duration on
> Airflow, can landing times on Airflow, can clear on Airflow, can tree on
> Airflow, can dag details on Airflow, can dagrun clear on Airflow, can code on
> Airflow, can tries on Airflow, can get logs with metadata on Airflow, can run
> on Airflow, can gantt on Airflow, can success on Airflow, can delete on
> Airflow, can paused on Airflow, can task instances on Airflow, can trigger on
> Airflow, can xcom on Airflow, can graph on Airflow, can dag stats on Airflow,
> can list on DagModelView, can show on DagModelView, can edit on DagModelView,
> can version on VersionView, can list on DagRunModelView, can add on
> DagRunModelView, muldelete on DagRunModelView, set failed on DagRunModelView,
> set running on DagRunModelView, set success on DagRunModelView, menu access
> on DAG Runs, menu access on Browse, can list on JobModelView, menu access on
> Jobs, can list on LogModelView, menu access on Logs, can list on
> SlaMissModelView, menu access on SLA Misses, can list on
> TaskInstanceModelView, clear on TaskInstanceModelView, set failed on
> TaskInstanceModelView, set running on TaskInstanceModelView, set success on
> TaskInstanceModelView, menu access on Task Instances, menu access on
> Documentation, menu access on Docs, menu access on Version]{code}
>
>
> I guess this is a bug? or is it something which I have done wrong with my DAG
> definition.
> Another note: The Admin role has 2 permissions for each DAG(dag edit and dag
> read). Will this work alright when we scale up to 1000s of DAGs?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
