fix: restore report owner verification on Keycloak by using SA roles

[rhartuv]

Summary

• Fix POST /api/v1/reports/failed owner verification on Keycloak (external-idp): stop using instanceof JsonWebToken to tell humans from service accounts.
• Detect service accounts via configured roles (exploitiq.security.service-account-roles), so ownership checks work across OpenShift OAuth and Keycloak.
• Cover SA bypass in ReportServiceAuditTest.

Problem

requiresOwnerVerification() treated any JWT principal as a service account. That works on OpenShift OAuth (only SAs use JWTs), but on Keycloak both humans and SAs use JWTs — so owner verification was skipped for everyone, and any authenticated user could mark another user's reports as failed.

Fix

Replace JWT-type coupling with a role check against configured service-account roles (@ConfigProperty, outside the exploit-iq.* AppConfig mapping so native builds do not resolve ${NAMESPACE} at image-build time):

• OpenShift: system:serviceaccounts:${NAMESPACE}:exploit-iq-sa, ...:pipeline
• Keycloak: exploitiq-api-access
  Human callers still require metadata.user to match the actor; SA-role callers skip ownership checks.

Jira

[vbelouso]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[rhartuv]

/retest

[zvigrinberg]

Hi @rhartuv

The idea is good, and it should work as expected.
Just one configuration trick, that will improve a lot the configuration maintainability .

Thank you.

[zvigrinberg]

@rhartuv Use here property expression that will expand the property values into the list here ( instead of hard-coding the service account names one after another), in order to prevent maintenance burden of keeping the values aligned, which is error prone

quarkus.http.auth.policy.role-policy.roles-allowed=exploit-iq-view,exploit-iq-prodsec,exploit-iq-admin,${exploitiq.security.service-account-roles}

[zvigrinberg]

@rhartuv This is redundant and just maintenance burden which is tend to be error prone
[See above] (#279 (comment))

[zvigrinberg]

@rhartuv
1 Final comment, PTAL.

Thank you.

[zvigrinberg]

@rhartuv It's already defined here in development profile.

[zvigrinberg]

@rhartuv You don't need the default for NAMESPACE env var expansion, as it's already defined in the development profile property entry in the configuration file for development purposes.
On cluster environments the NAMESPACE env var is always populated using the K8 Downward API' fieldRef facility/feature. ( it's getting the metadata.namespace value of the pod injected into this env var).

Suggested change

	exploitiq.security.service-account-roles=system:serviceaccounts:${NAMESPACE:local-dev}:exploit-iq-sa,system:serviceaccounts:${NAMESPACE:local-dev}:pipeline,exploitiq-api-access
	exploitiq.security.service-account-roles=system:serviceaccounts:${NAMESPACE}:exploit-iq-sa,system:serviceaccounts:${NAMESPACE}:pipeline,exploitiq-api-access

See #279 (comment)

[zvigrinberg]

@rhartuv LGTM Approved

Found former blocking bug

[zvigrinberg]

@rhartuv Just found out now, this is a regression, it causing 403 on environment.

Suggested change

	exploitiq.security.service-account-roles=system:serviceaccounts:${NAMESPACE}:exploit-iq-sa,system:serviceaccounts:${NAMESPACE}:pipeline,exploitiq-api-access
	exploitiq.security.service-account-roles=system:serviceaccount:${NAMESPACE}:exploit-iq-sa,system:serviceaccount:${NAMESPACE}:pipeline,exploitiq-api-access

[rhartuv]

Sorry, my bad. Fixing

[zvigrinberg]

@rhartuv There was a more deep cause (beyond that) , I've fixed it...

[rhartuv]

I will rebase after you merge

[zvigrinberg]

@rhartuv It merged ( #281) , you can rebase.

afterwards, Kindly test on your cluster environment ( eiq-rht ) using the temporary pr image tag, to see it goes well with a simple invocation of an analysis ( DOD -> agent-> client communication is valid and works as expected, the result sent correctly from agent to client , and shown in UI).

Thank you!

[rhartuv]

afterwards, Kindly test on your cluster environment ( eiq-rht ) using the temporary pr image tag, to see it goes well with a simple invocation of an analysis ( DOD -> agent-> client communication is valid and works as expected, the result sent correctly from agent to client , and shown in UI).

Done