feat(reports): implement report request filtering, config default filter

[andrewazores]

Welcome to Cryostat! 👋

Before contributing, make sure you have:

• Read the contributing guidelines
• Linked a relevant issue which this PR resolves
• Linked any other relevant issues, PR's, or documentation, if any
• Resolved all conflicts, if any
• Rebased your branch PR on top of the latest upstream main branch
• Attached at least one of the following labels to the PR: [chore, ci, docs, feat, fix, test]
• Signed all commits using a GPG signature

To recreate commits with GPG signature git fetch upstream && git rebase --force --gpg-sign upstream/main

---

Related to cryostatio/cryostat-core#527
Related to #859
Depends on cryostatio/cryostat-core#538
Depends on cryostatio/cryostat-reports#339

Description of the change:

1. Completes implementation of the old half-baked feature to allow filtering of report generation so that only particular automated analysis rules are executed. On the standard HTTP API this is done via query parameter, and on the GraphQL side it is done by a filter input.
2. Implements passing the filter string through to any report generator sidecar as well.
3. Adds a property to allow administrators to configure the Cryostat server to ignore particular analysis rules by default (or conversely to only execute particular rules by default) in case they are never concerned about the results of particular analyses. This might be the case in a Kubernetes deployment for example, where the Cryostat administrator is integrated with or close to the Java application team and they have all agreed that storing ex. a database password in a Secret which is mounted to the application via environment variable is acceptable in their security model and they all do not want to be bothered with the "Passwords in Environment" rule results.

How to manually test:

1. Check out this PR and its dependencies. Build.
2. ./smoketest.bash -O -t quarkus-cryostat-agent -r
3. Test report generation. Nothing should have changed in the normal UI-driven case. Take note of the PID1 and Passwords in Environment results for various targets.
4. https --auth=user:pass :8443/api/v4/targets/{targetId}/reports/{recordingId}?filter=some_id, where targetId is some ID from /api/v4/targets, recordingId is a remoteId from /api/v4/targets/{targetId}/recordings, and some_id is a rule ID from /api/v4.1/reports_rules. some_id can also be a comma-separated list, and can actually be rule IDs or topics, and can be negated by prefixing with !. The parser is not very sophisticated, so any negations should only follow after using the * wildcard - so to ignore a particular ID, use *,!id as the filter text. To process only particular IDs, use id1,id2 as the filter text.
5. Check https --auth=user:pass :8443/api/v4/recordings and use a reportUrl from one of the results to issue a follow-up request, appending ?filter=some_id as above, ex. $ https --auth=user:pass ':8443/api/v4/reports/ZEVfcE5vazJDak5Sc1hzV0FHTWpoT0k4VUtTcTlUb3pzb3Z1cmZ1UlotUT0vLWRlcGxveW1lbnRzLXF1YXJrdXMtcnVuLWphcl9vbnN0YXJ0XzIwMjUwNDE2VDE5MzAwNVouamZy?filter=*,!PID1Rule,!PasswordsInEnvironment'
6. Since these requests are now no longer directly returned but instead handled by the long-running job API, you will need to issue a follow-up response after processing has completed in order to view the result. In the case of archived recordings, be sure to select one that has not already been previously analyzed (ex. due to autoanalyze label) or else the filter will take no effect since the report has already been generated. Try firing the request using the CLI (to append the filter query) and using the UI to view the resulting report.
7. ctrl-c to tear down the smoketest. Edit the compose/cryostat.yml and add under environment: an entry like CRYOSTAT_SERVICES_REPORTS_FILTER=*,!PID1Rule,!PasswordsInEnvironment, then bring the smoketest back up.
8. Check active analysis and archived recordings analyses and ensure that the PID1 and Passwords in Environment results are now always N/A for all targets.

[github-actions]

Build Error! No Linked Issue found. Please link an issue or mention it in the body using #<issue_id>

[Josh-Matsuoka]

Tested via API calls and environment variable + web client, filtering works as expected and results are N/A as expected.

Do you think it's worth adding a notification so that web client users are aware that filtering is being done at least until a proper frontend is made for this?

[andrewazores]

I wasn't thinking of building any frontend for this - it's a server deployment-time configuration property for instance admins, at least how it's currently defined, so I'm not even sure what the frontend would be. There can/should be configuration properties on the Helm chart and Operator CR to control these things, but that would be the closest thing.

What kind of notification would you expect to see?

[andrewazores]

/build_test

[github-actions]

Workflow started at 6/24/2025, 5:15:31 PM. View Actions Run.

[github-actions]

No GraphQL schema changes detected.

[github-actions]

OpenAPI schema change detected:

diff --git a/schema/openapi.yaml b/schema/openapi.yaml
index 3fdc85b..2b061f0 100644
--- a/schema/openapi.yaml
+++ b/schema/openapi.yaml
@@ -949,21 +949,23 @@ paths:
               schema:
                 items:
                   $ref: '#/components/schemas/ReportRule'
                 type: array
           description: OK
         "401":
           description: Not Authorized
         "403":
           description: Not Allowed
       security:
-        - SecurityScheme: []
+        - SecurityScheme:
+            - read
+      summary: List Report Rules
       tags:
         - Reports
   /api/v4.1/targets/{targetId}/reports:
     get:
       description: |
         Get the current cached automated analysis report for the specified target, if any. If no such
         report currently exists for the specified target then the response will be an HTTP 404 Not Found,
         and automated analysis report generation will not be triggered.
       parameters:
         - in: path

[github-actions]

Schema changes committed by the CI.

[github-actions]

CI build and push: All tests pass ✅
https://github.com/cryostatio/cryostat/actions/runs/15861665538

[github-actions]

This PR/issue depends on:

• feat(reports): implement tokens for wildcard-all and id/topic negation cryostat-core#538
• chore(filter): refactor filter parser instantiation cryostat-reports#339
  By Dependent Issues (🤖). Happy coding!