The benefit of the solution I mention is simply that it can be implemented without changing Kafka, and I provided it more as a side note for people reading this list that might not have time to wait for this KIP to land into a released version. I do think that the KIP proposal would be very useful.
Cheers, noa > On 4 Dec 2020, at 19:02, Boyang Chen <reluctanthero...@gmail.com> wrote: > > Thanks Noa for the suggested path. Like you mentioned, I feel this > mechanism is a little bit overkill for a simple security file reloading > case. Could you provide more context on the benefit of doing a customized > KeyManager setup? TBH, I don't see Kafka going deep into these low level > security details yet. > > Best, > Boyang > > On Fri, Dec 4, 2020 at 4:02 AM Noa Resare <n...@resare.com> wrote: > >> 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 >> >>
