oscerd opened a new pull request, #26421:
URL: https://github.com/apache/camel/pull/26421
## What
Registers `camel-spiffe`'s `acceptAnySpiffeId` with the security policy
framework, so `camel.main.profile=prod` can flag it.
## Why
`SpiffeSSLContextParameters.acceptAnySpiffeId` turns off peer **identity**
pinning in mutual TLS: any SVID that chains to the trust bundle is accepted,
instead of an explicit `acceptedSpiffeIds` allow-list. The certificate is still
validated — but not *who* the peer is. That makes it the SPIFFE analogue of
disabling hostname verification, squarely an `insecure:ssl` option.
It carried no marker and was absent from `SecurityUtils`, so a deployment
running with `camel.main.profile = prod` — which per `design/security.adoc` is
meant to fail startup on `insecure:ssl` options — would not flag it. The
sibling component's comparable flag *is* flagged:
```java
map.put("failopen", new SecurityOption(INSECURE_DEV, "true")); // camel-opa
```
## Why the annotation alone would not have worked
`UpdateSensitizeHelper` builds the `SecurityUtils` map by scanning generated
component, dataformat and language JSON. `SpiffeSSLContextParameters` is a
standalone bean referenced through `sslContextParameters=#bean`, not a
component option, so its `@Metadata` fields never reach a component JSON — a
`security = "insecure:ssl"` marker on them is inert. This is the same gap
already known for `@Metadata(security=...)` on model/EIP/language elements.
The generator has an escape hatch for precisely this shape:
```java
// extra security options from camel-main properties that are not in
component JSON files
private static final String[][] EXTRA_SECURITY_OPTIONS = { ... };
```
## What changed
- `{ "acceptanyspiffeid", INSECURE_SSL, "true" }` added to
`EXTRA_SECURITY_OPTIONS`, with a comment explaining why this option cannot come
from the scan.
- The field annotated `security = "insecure:ssl"` for documentation value,
and its description expanded to say what the option actually gives up.
- Regenerated `SecurityUtils` now carries `map.put("acceptanyspiffeid", new
SecurityOption(INSECURE_SSL, "true"));`.
## Testing
`SecurityUtilsTest` already had a "verify known entries" case; it now also
asserts `acceptanyspiffeid` is present with the right category and insecure
value. Without that, deleting the `EXTRA_SECURITY_OPTIONS` entry would silently
un-register the option — which is the exact failure this PR fixes, so it is
worth a guard rather than trusting the generated file to stay put. 11 tests
green.
Full reactor build green — needed here rather than a module build, since the
packaging plugin has to be rebuilt before the catalog can regenerate
`SecurityUtils`.
`main` only.
_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]
