Common Configuration Issues
Resolve common configuration issues in Confluent for Kubernetes using the following steps.
Issue: An error caused by an extra semicolon character in the JAAS configuration
For Metadata Service (MDS) or KRaft client authentication, CFK might add an
unnecessary semicolon character (;) at the end of the content
referenced in the confluent.metadata.sasl.jaas.config property. This
results in having two semicolons (;) in the JAAS configuration
credential file or JAAS configuration
pass-through credential file,
and causes an error, such as Login module control flag is not available
in the JAAS config or Login module control flag not specified in JAAS
config:
kraftcontroller [ERROR] 2025-03-28 07:06:43,876 [main] kafka.Kafka$ error - Exiting Kafka due to fatal exception
kraftcontroller java.lang.IllegalArgumentException: Login module control flag is not available in the JAAS config
kraftcontroller at org.apache.kafka.common.security.JaasConfig.loginModuleControlFlag(JaasConfig.java:85)
Workaround: Use different secret keys for KRaft, Kafka, MDS and handle the trailing semicolon differently.
Create different keys in the secret client-jaas.conf,
kraftcontroller-client-plain-jaas.conf,
plain-jaas-confluent-metadata.conf, and plain-jaas.conf with the
following content:
For MDS and KRaft client authentication, remove the semicolon character
(;) from the credential file that the CR references, for example,
confluent.metadata.sasl.jaas.config for MDS.
client-jaas.conf:org.apache.kafka.common.security.plain.PlainLoginModule required \ username="{{ .username }}" password="{{ .password }}";kraftcontroller-client-plain-jaas.conf:sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \ username="{{ .username }}" password="{{ .password }}" \ user_{{.username }}="{{ .password }}"plain-jaas-confluent-metadata.conf:sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required \ username="{{ .username }}" password="{{ .password }}" \ user_{{.username }}="{{ .password }}"plain-jaas.conf:sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule \ username="{{ .username }}" password="{{ .password }}" \ user_{{.username }}="{{ .password }}";
Issue: Error for running Schema Registry with mismatching replication factor
The Schema Registry deployed with Confluent for Kubernetes uses the default replication factor of 3
for internal topics. When you deploy Schema Registry and Kafka simultaneously, and when
the Kafka brokers haven’t fully started, Schema Registry creates topics with a replication
factor that’s fewer than 3. Later, Schema Registry starts failing with an error.
For example, if Kafka has one broker running, and Schema Registry is trying to start, it
creates a topic with a replication factor of 1. Subsequently, when all
three brokers are running, Schema Registry issues an error that some topics have a
replication factor of only 1, and it fails to start.
Solution: Delete the Schema Registry deployment and redeploy after Kafka is fully up. Or
reconfigure the topics to align with the Schema Registry default replication factor of
3.
Issue: Unable to download connectors using on-demand URL
When using CFK init container 3.0.0 and
downloading connectors plugins using
onDemand.plugins.locationType.url.archivePath, you might see the
following error if the endpoint from which you pull the plugin
doesn’t have appropriate security mechanisms in place, such as using less
secure protocols during SSL handshake:
GnuTLS: One of the involved algorithms has insufficient security level.
Unable to establish SSL connection.
/mnt/plugins/kafka-connect-spooldir.zip: FAILED
Solution: Ensure that the endpoint specified in the Connect CR, for
onDemand.plugins.locationType.url.archivePath, is using secure
protocols. As an alternative, you can download the plugins from Confluent Marketplace
if the required plugins are available there.
Issue: OAuth Bearer Callback Handler class mismatch error
If you see the following error in Kafka logs, you might be using the incorrect
OAuth handler classes, such as with configOverrides.
org.apache.kafka.common.config.ConfigException: Invalid value
org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler
for configuration sasl.server.callback.handler.class: Class
org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler
could not be found.
In CFK 3.0.0 or later, the OAuth handler classes changed as follows:
org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandlerchanged toorg.apache.kafka.common.security.oauthbearer.OAuthBearerLoginCallbackHandler.org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandlerchanged toorg.apache.kafka.common.security.oauthbearer.OAuthBearerValidatorCallbackHandler.
Solution:
In CFK 3.0.0 or later, replace the callback handler classes with the newly supported classes.
Change
org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerLoginCallbackHandlertoorg.apache.kafka.common.security.oauthbearer.OAuthBearerLoginCallbackHandler.Change
org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandlertoorg.apache.kafka.common.security.oauthbearer.OAuthBearerValidatorCallbackHandler.
Note
For ksqlDB, if OAuth was already configured before you upgraded to Confluent Platform 8.0 or later, applying this solution might not resolve the error. Because ksqlDB replays the deprecated class from its internal command topic on restart, the configuration change alone doesn’t take effect. For assistance on how to correct the persisted command topic data, contact Confluent Support.