Thanks for the KIP. I think this would provide a solution that is very easy
to use. So it would work well with environments that are, for example,
manually managed. But I'm not convinced it is really a solution that would
cover every use case and situation. And as such it might not be sufficient.

The following limitations is something I would be concerned about:
* Reloading certificates based on some file watch event or on some
periodical polling might be challenging/risky when you need to change not
just the server certificate but also the CA. In such a case, you need to
first make sure the CA is trusted. And only then start rolling out the
server certificates issued by the new CA. If things happen out of order,
you can easily break your cluster. So in this situation, you will not be
able to just update the trust- and keystores. You would need to:
    1) Update the truststore with the new CA
    2) Wait for the truststore to be reloaded (How would one do this? Are
there any metrics?)
    3) Update the keystore with the new server certificate
    4) Wait for the keystore to be reloaded
    5) Remove the old CA from the truststore
    6) Wait for the truststore to be reloaded again
* The above is even harder on Kubernetes with the files mounted from
ConfigMaps / Secrets, where you actually have the mount point updated in a
non-deterministic interval in the first place.
* And staying with Kubernetes, from my experience, when I tried to
implement something similar in a different project, in many Kubernetes
environments, the Java file watching does not work very well for mounted
ConfigMaps or Secrets. It often does not work at all or indicates that the
file is changing all the time.

So I think this would be a useful feature for some situations. But it has
its limitations and is not solve all the various limitations Kafka has
around certificate reloading.

Thanks & Regards
Jakub

On Tue, Dec 3, 2024 at 12:12 AM Moncef Abboud <[email protected]>
wrote:

> Hi all,
>
> I hope your week is off to a great start.
>
> I created a KIP to add support for SSL hot reloading.
> https://cwiki.apache.org/confluence/x/eIrREw
>
> Thank you for your feedback!
>
>
> Moncef
>

Reply via email to