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.OAuthBearerLoginCallbackHandler changed to org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginCallbackHandler.

  • org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler changed to org.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.OAuthBearerLoginCallbackHandler to org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginCallbackHandler.

  • Change org.apache.kafka.common.security.oauthbearer.secured.OAuthBearerValidatorCallbackHandler to org.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.