DAG permission setting per owner and/or per tag

[mandicLuka]

Description

Access Control feature where one can limit a DAG permissions (read, write, etc.) for a group of DAGs, namely, the ones where owner is set or the tag is set to the desired value.

Use case/motivation

Restrict access for user to DAG read/write for all new DAGs created by the another user

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template!

[MM-Lehmann]

I think this is what the dag.access_control attribute is meant to do.

[mandicLuka]

Based on the documentation dag.access_control lets you set the permissions only for roles, not for individual users or owners.

[easontm]

See also #9342

[isaac-florence]

Agreeing with @potiuk's comment on #9342, airflow can't do multi-tenancy at the moment. However we have setup an instance which only uses the kubernetesPodOperator, and so can have multiple tenants coexisting where each tenant has their own k8s namespace/openshift project.
This model does require a central technician "approve" DAGs and merge requests to a dag repo to ensure that each tenant's dags only refer to their own namespace/project.
A further improvement of that model would be the implementation of this issue so that dags can be added to roles/groups based on their tag (or something else similar, like the owner), rather than the central technician adding dags to the tenant's role!
This does create literal security at the cost of staff time in reviewing dags/dag changes and time-to-deployment of new dags to be approved!

[potiuk]

Note that we have now Multi-tenancy effort in progress which I am leading. And while the first two AIPs that are very draft (but will soon be updated) do not address this final granularity yet, they pave the way for the third AIP that is going to address also this use case. Since this is in on the roadmap and planned and part of the bigger multi-tenancy effort, I am closing this one. @mandicLuka @easontm @isaac-florence if you are interested in joining the effort, please join Airlfow Devlist and possibly #sig-multitenancy slack channel and take part in the discussions:

You can find last meeting mintues and even recording of the meeting where we discussed the plans for Multitenancy. https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-1%3A+Improve+Airflow+Security

Note that this is for a long haul - full implementation of the multitenancy (and even discussion on the AIPs) will take quite some time (several months/half a year at the least as this is a really big set of features to make it possible).

[potiuk]

Or actually let me re-open it and add multi-tenancy label to group similar stuff together and refer to it when we will be implementing it.