Confluent Developer Marketplace Get started
  1. Home
  2. Platform
  3. CFK
  4. Troubleshoot Confluent for Kubernetes

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 CFK downloads connector plugins using spec.build.onDemand.plugins.url[].archivePath (see Download connector plugins from a custom URL), you might see the following error. The error occurs when the endpoint that hosts the plugin uses less secure protocols during the 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 for spec.build.onDemand.plugins.url[].archivePath uses secure protocols. As an alternative, you can download the plugins from Confluent Marketplace if the required plugins are available there.

If you can’t change the endpoint, check whether the automatic fallback from wget to curl succeeded. The download runs in the init container, so view its logs with kubectl logs <connect-cr-name>-0 -c config-init-container -n <namespace>, as described in View Connect init container logs. The preceding wget error appears in the log in both cases, so check whether the curl attempt that follows it succeeded or failed with its own error. Then do one of the following:

  • If the curl fallback succeeded, the plugin downloaded and the wget error is log noise. Set the platform.confluent.io/connector-force-curl annotation to "true" on the Connect CR to skip the wget attempt and avoid the noise.

  • If the curl fallback also failed, use the platform.confluent.io/connector-curl-extra-args annotation to pass the curl options your environment requires, such as a specific TLS version or cipher suite for the handshake.

For more information, see Download connector plugins from a custom URL.

Caution

Don’t pass --no-check-certificate to wget, or -k or --insecure to curl, to work around this error. Disabling certificate verification exposes the plugin download to tampering. Options that allow an older TLS version or weaker cipher suites also lower the security of the download. Use those TLS or cipher options only as a temporary workaround until the endpoint is fixed.

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.