Aneesh Joseph created AIRFLOW-5024:
--------------------------------------
Summary: 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
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)
