[
https://issues.apache.org/jira/browse/CAMEL-24731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18115393#comment-18115393
]
Claus Ibsen commented on CAMEL-24731:
-------------------------------------
Merged in https://github.com/apache/camel/pull/26421
_Claude Code on behalf of davsclaus_
> camel-spiffe - acceptAnySpiffeId is invisible to the security policy framework
> ------------------------------------------------------------------------------
>
> Key: CAMEL-24731
> URL: https://issues.apache.org/jira/browse/CAMEL-24731
> Project: Camel
> Issue Type: Improvement
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Minor
> Fix For: 4.23.0
>
>
> h2. Problem
> {{SpiffeSSLContextParameters.acceptAnySpiffeId}} turns off peer *identity*
> pinning in mutual TLS: any SVID that validates against the trust bundle is
> accepted, instead of an explicit {{acceptedSpiffeIds}} allow-list. That is
> the SPIFFE analogue of disabling hostname verification - the chain is still
> checked, but not *who* the peer is.
> It carries no {{security}} marker, and it is not registered with the security
> policy framework:
> {noformat}
> $ grep -n "acceptany"
> core/camel-util/src/main/java/org/apache/camel/util/SecurityUtils.java
> (no match)
> {noformat}
> By contrast {{camel-opa}}'s comparable flag is registered, because it is
> annotated on a {{@UriParam}}:
> {noformat}
> map.put("failopen", new SecurityOption(INSECURE_DEV, "true"));
> {noformat}
> So a deployment running with {{camel.main.profile = prod}} - which is
> supposed to fail startup on {{insecure:ssl}} options per design/security.adoc
> - will not flag {{acceptAnySpiffeId=true}}.
> h2. Why the marker alone is not enough
> {{UpdateSensitizeHelper}} builds the {{SecurityUtils}} map by scanning the
> generated component/dataformat/language JSON models.
> {{SpiffeSSLContextParameters}} is a standalone bean referenced through
> {{sslContextParameters=#bean}}, not a component option, so its {{@Metadata}}
> fields never reach a component JSON and a {{security = "insecure:ssl"}}
> marker on them would be inert. See also the known gap where
> {{@Metadata(security=...)}} is only enforced for {{@UriParam}}.
> The generator already has an escape hatch for precisely this case:
> {code:java}
> // extra security options from camel-main properties that are not in
> component JSON files
> private static final String[][] EXTRA_SECURITY_OPTIONS = {
> { "devconsoleenabled", INSECURE_DEV, "true" },
> ...
> };
> {code}
> h2. Proposal
> * Annotate the field with {{security = "insecure:ssl"}} for documentation
> value.
> * Add {{{ "acceptanyspiffeid", INSECURE_SSL, "true" }}} to
> {{EXTRA_SECURITY_OPTIONS}} so the option is actually enforced, and let the
> generator regenerate {{SecurityUtils}}.
> * Confirm the regenerated {{SecurityUtils}} contains the entry (the generated
> file is committed, so CI would otherwise flag drift).
> h2. Scope
> {{main}} only. Touches {{camel-spiffe}} plus the packaging plugin and the
> generated {{SecurityUtils}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
