oscerd opened a new pull request, #26436:
URL: https://github.com/apache/camel/pull/26436
## What
Gives `OpaSecurityPolicy` the readiness check the producer got in
CAMEL-24644, and stops the two probes from being copies of each other.
## Why
CAMEL-24644 added a producer health check so an unreachable OPA server shows
up before it fails traffic. It covered the `opa:` producer only — and that is
the wrong way round:
- a **producer** that cannot reach OPA records a deny verdict the route can
inspect and act on;
- **`OpaSecurityPolicy`** throws `CamelAuthorizationException` and stops the
exchange outright.
The path that hard-fails *every* message had no health signal at all. This
was raised as an open question in CAMEL-24644 ("worth considering whether the
check belongs on `OpaSecurityPolicy` too — it has the same exposure but no
endpoint to hang a producer health check on") and left unresolved.
## What changed
**Registration.** The policy is a bean wrapped around a route segment, so it
has no producer and cannot use the `producers` repository the way `OpaProducer`
does. It registers with `HealthCheckRegistry.get(route.getCamelContext())` from
`beforeWrap`, guarded so it registers once however many routes one policy
instance wraps. Ids start `security-policy:opa-` and are built from `serverUrl`
+ `policyPath`, so two policies enforcing different servers stay distinct — and
are run through `URISupport.sanitizeUri`, since CAMEL-24717 showed how easily a
`bearerToken` reaches the health output through an id.
**Shared probe.** The two checks asked the same question of the same
endpoint in ~40 near-identical lines. That is the shape where someone adjusts a
timeout or adds a failure mode in one and silently misses the other, in
security-relevant code. Both now delegate to `OpaHealthProbe`, which also owns
the shared `HttpClient` (one per JVM — `HttpClient` only became `AutoCloseable`
in Java 21, so one per check would leak a selector thread on the Java 17
baseline).
**Injected clients.** Neither check registers when an `opaClient` was
supplied: it can point anywhere and neither the endpoint nor the policy can ask
it where, so probing the configured `serverUrl` would report on a server they
may never talk to. A health check that reports on the wrong server is worse
than none.
## Testing
Four new cases in `OpaSecurityPolicyHealthCheckTest`, driven through a real
route and a real `HttpServer`:
- the policy registers a check that reports UP against a healthy server
- the check id never carries the `bearerToken`
- an unreachable server reports DOWN with the reason
- nothing is registered when an `opaClient` was injected
44 tests green in the module. The 5 pre-existing
`OpaProducerHealthCheckTest` cases pass unchanged, which is what shows the
probe extraction preserved behaviour rather than merely compiling. Full reactor
build green.
`main` only. Additive.
_Claude Code on behalf of @oscerd_
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
