[
https://issues.apache.org/jira/browse/CAMEL-23995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-23995:
--------------------------------
Fix Version/s: 4.22.0
> camel-kafka: saslAuthType overrides explicit securityProtocol and generates
> non-working KERBEROS/OAUTH/AWS_MSK_IAM configurations
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-23995
> URL: https://issues.apache.org/jira/browse/CAMEL-23995
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka
> Reporter: Federico Mariani
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.22.0
>
>
> Follow-up to CAMEL-22864 ({{saslAuthType}} option). Code review found that
> the auth-type convenience layer overrides explicitly configured security
> settings and generates non-working configurations for three of its auth
> types. Findings 1 was verified empirically by building properties from
> {{target/classes}}, not just by reading code. All line numbers refer to
> current {{main}} (4.22.0-SNAPSHOT).
> h3. 1. saslAuthType forcibly overrides an explicitly configured
> securityProtocol
> {{KafkaConfiguration#applyAuthTypeConfiguration}} (lines 452-465):
> {code:java}
> // For SASL types, default to SSL unless explicitly using SASL_PLAINTEXT
> if (saslAuthType.isSasl()) {
> boolean useSsl = !securityProtocol.equals("SASL_PLAINTEXT") &&
> !securityProtocol.equals("PLAINTEXT");
> configurer.withSsl(useSsl || hasSslConfig || saslAuthType !=
> KafkaAuthType.NONE);
> }
> {code}
> {{saslAuthType != KafkaAuthType.NONE}} is a tautology inside the {{isSasl()}}
> branch ({{NONE.isSasl()}} is false), so the carefully computed {{useSsl}} and
> {{hasSslConfig}} are dead and SSL is *always* forced on.
> Verified: {{saslAuthType=PLAIN&securityProtocol=SASL_PLAINTEXT}} →
> {{createConsumerProperties()}} yields {{security.protocol=SASL_SSL}}. The
> client attempts a TLS handshake against a plaintext listener and can never
> connect. The component's own ITs ({{KafkaConsumerSaslAuthTypeIT}},
> {{KafkaProducerSaslAuthTypeIT}}) use exactly this combination — they are
> gated on {{kafka.instance.type}} and skipped in default builds, which is why
> this went unnoticed.
> Also verified the converse: {{saslAuthType=NONE}} + explicit
> {{securityProtocol=SSL}} + {{sslTruststoreLocation}} set → downgraded to
> {{security.protocol=PLAINTEXT}} (the SASL block is skipped and
> {{hasSslConfig}} is never used for NONE) — a silent encryption downgrade.
> Fix: {{configurer.withSsl(useSsl || hasSslConfig)}} and handle the NONE/SSL
> case so an explicit protocol is never overridden.
> h3. 2. saslAuthType=KERBEROS always throws at startup
> For KERBEROS, {{applyAuthTypeConfiguration}} deliberately configures nothing
> ("we still use the existing kerberos properties"), but
> {{KafkaSecurityConfigurer.configure()}} → {{buildJaasConfig()}} →
> {{validateKerberos()}} requires {{kerberosPrincipal}}/{{kerberosKeytab}} —
> which have *no corresponding @UriParam* on {{KafkaConfiguration}} and no code
> path that sets them ({{withKerberos}} is never called from Camel).
> Verified: {{saslAuthType=KERBEROS}} → {{IllegalArgumentException: Kerberos
> principal is required for KERBEROS authentication}} — always. The feature is
> unusable.
> Fix options: add {{kerberosPrincipal}}/{{kerberosKeytab}} URI options, or
> make KERBEROS skip JAAS generation (rely on external JAAS/krb5) and only set
> protocol+mechanism, as the code comment claims it does.
> h3. 3. saslAuthType=OAUTH and saslAuthType=AWS_MSK_IAM generate
> configurations that cannot authenticate
> {{KafkaSecurityConfigurer}} (lines 335-347):
> * OAUTH: generates JAAS {{OAuthBearerLoginModule required clientId="..."
> clientSecret="..." oauth.token.endpoint.uri="...";}} — a hybrid matching
> neither convention. Kafka's built-in KIP-768 support needs top-level
> {{sasl.oauthbearer.token.endpoint.url}} *and*
> {{sasl.login.callback.handler.class=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginCallbackHandler}}
> (neither is set; without it Kafka falls back to the *unsecured* login
> callback handler which ignores clientId/clientSecret). The Strimzi library
> (which the component docs document) uses
> {{oauth.client.id}}/{{oauth.client.secret}} JAAS keys and needs the Strimzi
> callback handler — also not set, and the generated key names don't match.
> * AWS_MSK_IAM: generated props contain only
> {{sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required;}} —
> the mandatory
> {{sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler}}
> is missing, so authentication fails at connect.
> There are no ITs covering OAUTH/AWS_MSK_IAM (only string-level assertions in
> {{KafkaSecurityConfigurerTest}}).
> Fix: inject the needed callback-handler / endpoint configs and pick one OAuth
> convention (KIP-768 is dependency-free).
> h3. Related hardening (same rework)
> * {{createProducerProperties()}}/{{createConsumerProperties()}} mutate the
> endpoint's {{KafkaConfiguration}} ({{applyAuthTypeConfiguration}} writes
> {{securityProtocol}}/{{saslMechanism}}/{{saslJaasConfig}} back) — a factory
> method with config side effects; consider computing into the {{Properties}}
> only.
> * {{oauthTokenEndpointUri}} is not escaped in the generated JAAS string,
> unlike clientId/clientSecret ({{escapeJaasValue}}).
> * Integration-test coverage for the auth types should run somewhere in CI,
> otherwise this class of bug returns.
> ----
> _This issue was researched and written by Claude Code on behalf of Federico
> Mariani (GitHub: Croway). Findings were verified against the source and git
> history before filing._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
