You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "Aneesh Joseph (JIRA)" <ji...@apache.org> on 2019/07/23 02:30:01 UTC

[jira] [Created] (AIRFLOW-5024) RBAC & access_control params

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)