Instead of a java file watch on files mounted from CMs or secrets in k8s, could we add amend the consumer and producer APIs to allow reloading SSL config from the application? This would offload the environment specific complexities.
Regards, ________________________________ From: Jakub Scholz <[email protected]> Sent: Sunday, September 7, 2025 21:01 To: [email protected] <[email protected]> Subject: Re: [DISCUSS] KIP-1119: Add support for SSL hot reload [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] EXTERNAL SENDER. Do not click links or open attachments unless you recognize the sender and know the content is safe. DO NOT provide your username or password. 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://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fx%2FeIrREw&data=05%7C02%7Cmartin.andersson%40kambi.com%7C94d098c237844176e6de08ddee41375f%7Ce3ec1ec4b9944e9e82e080234621871f%7C0%7C0%7C638928686092640663%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EYje3QM3XM1xPwnZ%2FTFJV%2B1ojsTkByhZlKyWYwYrTAA%3D&reserved=0<https://cwiki.apache.org/confluence/x/eIrREw> > > Thank you for your feedback! > > > Moncef > CONFIDENTIALITY NOTICE: This email message (and any attachment) is intended only for the individual or entity to which it is addressed. The information in this email is confidential and may contain information that is legally privileged or exempt from disclosure under applicable law. If you are not the intended recipient, you are strictly prohibited from reading, using, publishing or disseminating such information and upon receipt, must permanently delete the original and destroy any copies. We take steps to protect against viruses and other defects but advise you to carry out your own checks and precautions as Kambi does not accept any liability for any which remain. Thank you for your co-operation.
