[bitnami/kafka] bug: provisioning job will fail when startup kafka with ssl

[chenraoCR]

Name and Version

bitnami/kafka:32.2.2

What architecture are you using?

None

What steps will reproduce the bug?

1. deploy bitnami/kafka:32.2.2 helm chart, kafka-controller can startup, but kafka-provisioning job will fail

Are you using any custom parameters or values?

listeners:
  client:
    protocol: SSL
tls:
  type: pem
  existingSecret: kafka-tls-secret
provisioning:
  enabled: true
  topics:
    - name: test
  auth:
    tls:
      type: pem
      certificatesSecret: kafka-tls-secret

What is the expected behavior?

kafka-controller pod should startup and also kafka-provisioning job should succeed and topic test should be created

What do you see instead?

kafka-provisioning job failed

Additional information

the initContainer wait-for-available-kafka will failed as in the container, it will use kafka client properties file, if kafka startup with ssl, means we set .Values.listeners.client.protocol to SSL, then in client.properties file, we make ssl related settings, but we did not mount the certs into this initContainer

we should also set as followings in wait-for-available-kafka https://github.com/bitnami/charts/blob/32d8701105619dced44cb5a8cf981c7d8a91c98b/bitnami/kafka/templates/provisioning/job.yaml#L291-L297

[javsalgar]

Hi!

Thank you so much for spotting the issue. I will forward it to the team but we cannot guarantee an ETA. If you want to speed up the process, you can submit a PR updating the init container so it takes into account the ssl settings.

[aparedero]

Hello, I found the same issue. I have tried autogenerating TLS certificates with helm engine, autogenerating with cert-manager and last but not least, issuing a certificate and attaching it manually via tls.existingSecret. Provisioning was working fine while using PLAINTEXT.

@javsalgar , troubleshooting the error on provisioning I found that first initContainer prepare-config is failing:

kubectl logs -n kafka kafka-provisioning-1234k -c prepare-config
environment: line 11: /certs/tls.key: No such file or directory
environment: line 11: /certs/tls.crt: No such file or directory
environment: line 11: /certs/ca.crt: No such file or directory

In provisioning-job.yaml I see that main provisioning container does have this block, but not the initContainer.

        {{- if (regexFind "SSL" (upper .Values.listeners.client.protocol)) }}
        {{- if not (empty .Values.provisioning.auth.tls.certificatesSecret) }}
        - name: kafka-client-certs
          secret:
            secretName: {{ .Values.provisioning.auth.tls.certificatesSecret }}
            defaultMode: 256

since initContainer is not mounting /certs, it never finds the files tls.key, tls.crt and ca.crt.

I'm going to test this on a personal environment, should I missing something else while attaching the volume?

[javsalgar]

Hi,

It could be that the init container is missing the volumeMount. What you are showing is the volumes section. Could you check if the init container has the volumeMount set?

[github-actions[bot]]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[michaelvwu]

@javsalgar The initcontainer is missing the volumeMount for kafka-client-certs. When I peaked in the wait-for-kafka initcontainer, it only shows shared, as it found the config file, but the /certs directory was missing and I could not navigate to it.

[javsalgar]

Hi, so it seems that the only missing item would be to add that volume mount to that init container, is that correct?

[chenraoCR]

Hi, so it seems that the only missing item would be to add that volume mount to that init container, is that correct?

ya, correct

[github-actions[bot]]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions[bot]]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.