Revoking audit_log permission from all users except admin

[amoghrajesh]

The viewer role and any other users apart from admin don't need to have audit_log permissions. Revoking it.

Alternatively, I moved the revoked permissions to ADMIN_PERMISSIONS.

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[amoghrajesh]

The UI elements dont render for audit_logs:

Forbidden /api/v1/eventLogs:

If I try to access audit logs from the DAG run details:
https://github.com/apache/airflow/assets/35884252/96f9fdf9-d203-4482-8635-0bc467fa46d3

[hussein-awala]

I agree with you that only admin (and custom roles) should have these permissions, but I don't know if we can consider this a bug fix, because otherwise it will be considered a breaking change. (not a big problem anymore after creating fab provider)

[potiuk]

LGMT. Few nits that should be resolved.

[potiuk]

I agree with you that only admin (and custom roles) should have these permissions, but I don't know if we can consider this a bug fix, because otherwise it will be considered a breaking change. (not a big problem anymore after creating fab provider)

Yes. Bug-fix. It should not be there in the first place IMHO.

[potiuk]

But also we should add a .significant entry in newsfragments about it @amoghrajesh

[eladkal]

But also we should add a .significant entry in newsfragments about it @amoghrajesh

yeah it's a bit tricky?
The news fragment should be in Airflow 2.9.0 but the actual code change is in the fab provider.

[potiuk]

Not tricky. We agreed with @vincbeck that when we cherry-pick FAB things for 2.8.0, we will cherry-pick them to core - moving the changes back where they were in before 2.9, so once we cherry-pick this one with a newsfragment, it will nicely go into 2.8.2 (or 2.8.3 whatever it will be released in)

[eladkal]

Not tricky. We agreed with @vincbeck that when we cherry-pick FAB things for 2.8.0, we will cherry-pick them to core - moving the changes back where they were in before 2.9, so once we cherry-pick this one with a newsfragment, it will nicely go into 2.8.2 (or 2.8.3 whatever it will be released in)

Not sure that I get that?
The fab provider will be functional only for Airflow 2.9.0 does it not?
so only when user is upgrading to Airflow 2.9.0 the user will notice the change thus adding it to newsfragmant of 2.8.2 is not helpful.

[potiuk]

No. This issue can be cherry-picked to 2.8.2 to the place where Fab was previously. We've already done that

[potiuk]

When we separated FAB provider right after we created 2.8.0 - this was what we agreed to with @vincbeck - that security related and small fixeds will be cherry picked to 2.8.* airflow core

[amoghrajesh]

Thanks for the reviews! @potiuk / @eladkal pushed a newsfragment

@jedcunningham nits handled

[amoghrajesh]

@potiuk do I have to do anything with respect to cherry picking to earlier branches?

[potiuk]

@potiuk do I have to do anything with respect to cherry picking to earlier branches?

Thanks for the offer :). We'll handle it. Usually cherry-picking is done by release managers and those who directly help them and are familiar with the process - becuase this is rather delicate process and there are a number of decisions to made on the spot (currently those people are @ephraimbuddy @jedcunningham @eladkal and myself mostly. So doing it just for one PR introduces potential more issues than it solves. But if at some point in time you would like to join the release team and cherry-pick next changes (after seeing how it's done - absolutely :D . Just look what's dicussed in #release-management channel and follow it, and then raise hand before the release. Though - extra care is needed while doing it

[amoghrajesh]

@potiuk do I have to do anything with respect to cherry picking to earlier branches?

Thanks for the offer :). We'll handle it. Usually cherry-picking is done by release managers and those who directly help them and are familiar with the process - becuase this is rather delicate process and there are a number of decisions to made on the spot (currently those people are @ephraimbuddy @jedcunningham @eladkal and myself mostly. So doing it just for one PR introduces potential more issues than it solves. But if at some point in time you would like to join the release team and cherry-pick next changes (after seeing how it's done - absolutely :D . Just look what's dicussed in #release-management channel and follow it, and then raise hand before the release. Though - extra care is needed while doing it

Thank you, i was aware of the people who do it, and slightly about the process too, thanks for clarifying. I was curious if anything special was needed because this is a different kind of fix. Got it cleared now, thanks