Moncef, Is this work something you're still interested in pursuing? I'm looking at something similar to this, but mostly from the client perspective.
Thanks, Kirk On Tue, Sep 9, 2025, at 6:09 AM, Martin Andersson wrote: > 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. >
