[jira] [Updated] (CAMEL-24731) camel-spiffe - acceptAnySpiffeId is invisible to the security policy framework

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-24731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen updated CAMEL-24731:
--------------------------------
    Fix Version/s: 4.23.0

> 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)