oscerd opened a new pull request, #26664:
URL: https://github.com/apache/camel/pull/26664
## What
Adds `CamelOpaDecisionFailedOpen`, set only when an exchange proceeded
because `failOpen` is enabled and the policy could not be evaluated.
## Why
`CamelOpaDecisionAllow` is `true` in two very different situations: a policy
allowed the exchange, and no policy ran at all but `failOpen` told the
component to continue. On its own the header cannot separate them, so neither a
route nor an audit trail can answer "which exchanges went through
unauthorized?".
The only existing signal was a WARN in the application log:
```java
LOG.warn("Policy {} could not be evaluated, allowing the exchange to proceed
because failOpen is enabled...");
```
"This route is currently allowing traffic nothing authorized" is precisely
the condition an operator wants to alert on, and an application log is the
weakest channel available for it — easy to lose in volume, invisible to metrics.
## How
The marker is set on the fail-open path and nowhere else, so its
**presence** is the signal:
```java
.choice()
.when(header(OpaConstants.DECISION_FAILED_OPEN).isEqualTo(true))
.to("log:unauthorized?level=WARN")
.end()
```
It is cleared before every evaluation along with the other decision headers.
That is not incidental: without it a sender could preload
`CamelOpaDecisionFailedOpen=false` and disguise an unauthorized exchange as one
a policy allowed, which would make the header worse than useless given it
exists to be an audit trail. This is the same attacker-settable-header problem
CAMEL-24754 fixed for the verdict itself, and it applies identically to any
future marker.
## Testing
Four cases in `OpaProducerTest`:
- the marker appears when `failOpen` carried the exchange
- it is **absent** on an allow a policy actually made — the separation is
the whole point
- a sender cannot claim `false` on the fail-open path
- a claimed marker is cleared on an ordinary decision
Removing the `clearDecisionHeaders` line turns the last one red. 86 tests in
the module, full reactor green.
## Scope
`main` only, additive. `failOpen` remains `false` by default and marked
`insecure:dev`.
This is Option 1 of the three in the issue. Option 2 (the health check
reporting DEGRADED while a route is failing open) is deliberately not included
— it needs the evaluator to publish state to the check, which is a different
change and worth its own review.
_Claude Code on behalf of @oscerd_
--
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]
