Thanks for the feedback Nikolay. I think our proposals are solving orthogonal issues. The KIP is proposing to deprecate the reloading path on AlterConfig, which has nothing to do with general certification expire issue.
Best, Boyang On Fri, Dec 4, 2020 at 4:26 AM Nikolay Izhikov <nizhi...@apache.org> wrote: > Hello, Boyang Chen. > > I think this KIP overlaps with my idea [1] of exposing information about > certificates Kafka uses. > Kafka administrator should initiate renewal certificates procedure not > long before the certificate expires. > But, for now, there is no way for administrators to know the expiration > date of the certificate. > My proposal is to expose this info in the describe command. > > What do you think? > Do we need it? > > [1] > https://mail-archives.apache.org/mod_mbox/kafka-dev/202012.mbox/browser > > > > 4 дек. 2020 г., в 15:00, Noa Resare <n...@resare.com> написал(а): > > > > Hi Boyang, > > > > I think that it would improve the ergonomics of dealing with short lived > certificates to have this be the default behaviour. > > > > It should be noted that transparently reloading certificates and keys > when they changed on disk can be implemented right now registering a custom > KeyManagerFactory, but to say that the JDK is designed to make this easy > would be an overstatement. The things that we do to get this working: > > > > 1. Create a class implementing SecurityProviderCreator that will return > a Provider that registers a custom KeyManagerFactory implementation. > > 2. This custom KeyManagerFactory would return KeyManager instances that > implements X509ExendedKeyManager > > 3. The custom KeyManager would return cached but up to date values for > the getCertificateChain() and getPrivateKey() methods. > > 5. Configure Kafka with security.providers referencing the class defined > in 1) > > > > This is not something I would wish upon anyone, but it works. Solving > this for everyone inside Apache Kafka seems like a much preferred solution. > > > > Cheers > > noa > > > > ps. It seems my apple.com <http://apple.com/> email address ends up on > the list as apple.com <http://apple.com/>.INVALID. Is this a known > problem? For now I’m working around it by using my personal email. > > > >> On 4 Dec 2020, at 01:28, Boyang Chen <reluctanthero...@gmail.com> > wrote: > >> > >> Hey there, > >> > >> I would like to start the discussion thread for KIP-687: > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-687%3A+Automatic+Reloading+of+Security+Store > >> > >> This KIP is trying to deprecate the AlterConfigs API support of updating > >> the security store by reloading path in-place, and replace with a > >> file-watch mechanism inside the broker. Let me know what you think. > >> > >> Best, > >> Boyang > > > >
