Dag level rbac for backfills

[pierrejeambrun]

Body

In #47482 we decided to handle the permission of backfills through a new entity BackfillDetails which isn't related to a Dag.

Now I'm second guessing this, because it is currently not possible to do permission filtering based on Dag access. Similarly to other DagAccessEntity I think it would be beneficial to be able to filter access to backfills based on Dag permissons. Currently giving access to 'read on DAG:SomeDag' does not give any access on the related backfills.

The idea is that 'backfills' really exist as a sub entity of a Dag, they cannot exist by themselves in contradiction to other Details such as VariableDetails PoolDetails etc...

Committer

• I acknowledge that I am a maintainer/committer of the Apache Airflow project.

[vincbeck]

The idea is that 'backfills' really exist as a sub entity of a Dag

If that's the case then I agree, it makes total sense to make Backfill not a top level entity but a sub entity of Dag in our auth model.

The small complexity we might have is, many backfill APIs do not have any reference to dag_id (e.g. get_backfill) so we might need to make an additional query to get the dag_id and pass it to the auth manager.

Another topic but kind of related, if backfills are really sub entity of Dags, then we should probably have this relation in the api as well. Example: /api/dag/123/backfill/456 instead of /api/backfill/456. And that's true for the other dag sub entities. That's the definition of Rest. But given this is a breaking change, it is probably not worth exploring that.

[vincbeck]

If we go down that path I think we need:

• Deprecate is_authorized_backfill
• Add Backfill to DagAccessEntity
• Potentially update auth manager implementations to take into consideration this new value. I do not think this is needed cause no auth manager that I am aware of does case by case logic with DagAccessEntity
• Communication to users because if some users are using KeycloakAuthManager or AwsAuthManager, then they might need to make some modifications to their authz policies