Require DATASOURCE WRITE access in SupervisorResourceFilter and TaskResourceFilter

[kfaraz]

Description

Users with DATASOURCE READ access can currently call GET and HEAD APIs
on Supervisor and Task resources. These resources respond with ingestion related
information, which should be visible only to DATASOURCE WRITE users.

Changes

• Always require DATASOURCE WRITE access in SupervisorResourceFilter and TaskResourceFilter

---

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[clintropolis]

👍 makes sense to me

[suneet-s]

@kfaraz Is it possible to add integration tests that call all the different endpoints that are available on the ingest path and validate that a user needs DATASOURCE WRITE permission to see .

I skimmed the code and noticed users with DATASOURCE READ can see metadata about the segments. I think this seems ok since a DATASOURCE READ user may need to know which segments were available when a query was executed so they would have a need.

I dug a little bit and it seems like the segment metadata could include the loadSpec. Do you think that should also require DATASOURCE WRITE permissions?

[suneet-s]

This change LGTM with 2 comments

1. Can we add integration tests - maybe piggybacking off some of the security based integration tests?
2. What should we do about segment metadata - should that require DATASOURCE WRITE?

Neither of these comments are blockers to this PR, so I'm approving the PR - but we might want fast follow ups to address these points

[kfaraz]

Thanks for the review, @suneet-s . I will add an integration test in a follow up PR (hopefully within a couple of days). I will also spend some time on the access of segment metadata and propose required changes, if any.

[clintropolis]

I missed a couple of things in my initial review, SQL queries to sys.tasks and sys.supervisors still use read permissions and a handful of task report APIs also still use read instead of write

so this change isn't quite yet complete I think. (I do still think WRITE makes more sense for the changes here and all of these APIs). I'm not sure if I missed any others, probably worth having another look.

[kfaraz]

Thanks for checking, @clintropolis . I am taking another pass at the APIs and will share the results of my findings here.

[suneet-s]

Removed milestone 0.22.0 since the backport PR was not merged