[Improvement] Restrict access to global audit logs

[HRsGIT]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

The org.apache.dolphinscheduler.api.controller.AuditLogController.queryAuditLogListPaging currently allows any authenticated regular user to view all system-wide audit logs. This includes sensitive activity logs generated by the admin user and other high-privileged accounts.

I would like to suggest an improvement regarding this behavior. In my view, allowing users without any administrative or project permissions (e.g., an intern) to access global audit logs may pose a potential risk of information disclosure.

The audit logs contain metadata that could be sensitive in certain environments, such as:

• Project Metadata: Creation/deletion timestamps and project names (which often reflect internal business focus or data structures).
• User Management: Global visibility of all usernames and user lifecycle events.
• Security Context: Activity records related to the management of security tokens.

While this information is necessary for administrators, providing it to all regular users might provide an unnecessary "system blueprint." Even the createTime can be sensitive, as it reveals operational patterns or helps in guessing time-based IDs.

Proposed Improvement: To better align with the Principle of Least Privilege, I suggest adding a permission check to the audit log logic:

• Regular Users: Restricted to viewing only their own activity logs.

• Administrators: Retain the full global view for system auditing purposes.

I believe this refinement would further enhance the security posture of DolphinScheduler for enterprise users.

An example:
The userA can not view any project.

Then we access the interface org.apache.dolphinscheduler.api.controller.AuditLogController.queryAuditLogListPaging. It is observed that all logs are returned, including the records of the admin creating userA and userB, as well as the records of userB creating a project, and the creation/update/deletion of security tokens.

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