Common Networking Issues

Resolve common networking issues in Confluent for Kubernetes using the following steps.

Issue: Confluent Control Center (Legacy) can’t use auto-generated certificates for MDS or Confluent Cloud Schema Registry

When TLS is enabled, and when Confluent Control Center (Legacy) uses a different TLS certificate to communicate with Metadata Service (MDS) or Confluent Cloud Schema Registry, Control Center (Legacy) can’t use an auto-generated TLS certificate to connect to MDS or Confluent Cloud Schema Registry.

Solution: To encrypt Confluent Control Center (Legacy) traffic to MDS or Confluent Cloud Schema Registry, provide custom TLS certificates:

1. Add to the Confluent Control Center (Legacy) TLS secret a custom truststore that includes the root CA to trust Confluent Cloud Schema Registry or MDS.

2. Use the preceding secret name in the Confluent Control Center (Legacy) custom resource (CR):

   spec:
     dependencies:
       mds:
         tls:
           secretRef: <custom Root CA>
   

3. Disable auto-generated certs and provide the RootCA in Confluent Control Center (Legacy) custom resource:

   spec:
     tls:
       autoGeneratedCerts: false
       secretRef: <custom Root CA>
   

4. Deploy or redeploy Confluent Control Center (Legacy).

Issue: ksqlDB can’t use auto-generated certificates for Confluent Cloud

When ksqlDB communicates with Confluent Cloud, ksqlDB can’t use an auto-generated TLS certificate.

Solution: To encrypt ksqlDB traffic to Confluent Cloud, provide custom TLS certificates:

1. Provide a custom truststore that includes the Let’s Encrypt Root CA.

2. Disable auto-generated certs and provide the RootCA in ksqlDB custom resource:

   spec:
     tls:
       autoGeneratedCerts: false
       secretRef: <custom Root CA>
   

3. Deploy or redeploy ksqlDB.

Issue: Kafka listeners can’t share the same TLS secret reference

For a Kafka custom resource, two different listeners, such as internal and external listeners, can’t share the same TLS secret reference. Configuring this impacts the volume mount path, and the statefulset fails.

Workaround: Use global TLS if you need to share TLS configuration, as shown in the following example:

spec:
  tls:
    secretRef: tls-shared-certs
  listeners:
    internal:
      tls:
        enabled: true
    external:
      tls:
        enabled: true

Fixed Version: Upgrade to CFK 2.0.2, which fixes this limitation.

Issue: TLS-enabled ksqlDB fails to start with a crash loop

Currently, ksqlDB doesn’t support using different trust stores for the REST client connections and the connections from ksqlDB to Kafka.

spec.dependencies.kafka.tls.ignoreTrustStoreConfig in the ksqlDB CR, used for a dependency on a component that doesn’t decouple HTTPS and TLS properties, doesn’t work if the ksqlDB REST endpoint has TLS enabled and if the Kafka dependency uses TLS.

For example, a ksqlDB with TLS enabled, auto-generate certificates, and spec.dependencies.kafka.tls.ignoreTrustStoreConfig set to true, fails with a crash loop. The following error appears in the ksqlDB log:

sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Workaround: Set spec.dependencies.kafka.tls.ignoreTrustStoreConfig: false in the ksqlDB CR and reapply the CR to re-start ksqlDB.