Harsha made a good point that you can achieve your goals through KIP-492. Security configuration is starting to get pretty complex-- is there a reason not to use the existing configurations?
Also, it seems like most people who want a custom truststore / keystore will also want a custom SSL provider, so that they can integrate their custom SSL infra with more applications than just Kafka. So I'm not sure how big the audience for the proposed new configurations would be. regards, Colin On Thu, Aug 8, 2019, at 15:29, Maulin Vasavada wrote: > Hi Harsha > > We don't have spire (or similar) agents and we do not have keys/certs > locally on any brokers. To elaborate more on my previous email, > > I agree that Java security Providers are used in much broader sense - to > have a particular implementation of an algorithm, use specific cipher > suites for SSL , OR in our current team's case have a particular way to > leverage pre-generated SSL sessions. However, the scope of our KIP (486) is > much restricted than that. We merely intend to provide a custom > keystore/truststore for our SSL connections and not really worry about > underlying specific SSL/TLS implementation. This simplifies it a lot for > us to keep the concerns separate and clear. > > I feel our approach is more complimentary such that it allows for using > keystores of choice while retaining the flexibility to use any > underlying/available Provider for actually making the SSL call. > > We agree with KIP-492's approach based on Providers (and Java's > recommendation), but also strongly believe that our approach can compliment > it very effectively for reasons explained above. > > Thanks > Maulin > > On Thu, Aug 8, 2019 at 3:05 PM Harsha Chintalapani <ka...@harsha.io> wrote: > > > Hi Maulin, > > > > On Thu, Aug 08, 2019 at 2:04 PM, Maulin Vasavada < > > maulin.vasav...@gmail.com> > > wrote: > > > > > Hi Harsha > > > > > > The reason we rejected the SslProvider route is that - we only needed a > > > custom way to load keys/certs. Not touch any policy that existing > > Providers > > > govern like SunJSSE Provider. > > > > > > > We have exactly the same requirements to load certs and keys through spire > > agent. We used security.provider to do that exactly. I am not sure why you > > would be modifying any policies provided by default SunJSSE provider. Can > > you give me an example of having custom provider that will override an > > existing policy in SunJSSE provider. > > > > As pointed out earlier, this kip > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-492%3A+Add+java+security+providers+in+Kafka+Security+config > > allows > > you to load security.provider through config. > > Take a look at the examples I gave before > > > > https://github.com/spiffe/spiffe-example/blob/master/java-spiffe/spiffe-security-provider/src/main/java/spiffe/api/provider/SpiffeProvider.java > > It registers KeyManagerFactory and TrustManagerFactory and Keystore > > algorithm. > > Implement your custom way of loading Keystore in here > > > > https://github.com/spiffe/spiffe-example/blob/master/java-spiffe/spiffe-security-provider/src/main/java/spiffe/api/provider/SpiffeKeyStore.java > > > > and Trust manager like here > > > > https://github.com/spiffe/spiffe-example/blob/master/java-spiffe/spiffe-security-provider/src/main/java/spiffe/api/provider/SpiffeTrustManager.java > > > > In your Kafka client you can set the security.provider to your custom > > implementation and with this fix > > https://issues.apache.org/jira/browse/KAFKA-8191 you can set > > keyManagerAlgorigthm and trustManagerAlgorithm configs. > > > > All of this is in your clients and broker side and do not need to touch any > > policy changes at JVM level. You'll register the providers in the priority > > order and can still have SunJSSE provider and have your custom provider to > > implement the key and trust managers. > > > > > > > > The ask here is different than KIP-492. We don't have any need to > > > modify/specify the algorithm parameter. Does that make sense? > > > > > > > The ask in KIP is introducing new interfaces where the KIP's > > goal/motivation can be achieved through the security.provider and we worked > > on similar goal without touching any Keystore or Truststore interfaces. > > My advise is against changing or introducing new interfaces when it can > > work through security.provider. > > > > Thanks, > > Harsha > > > > > > Thanks > > > Maulin > > > > > > On Thu, Aug 8, 2019 at 7:48 AM Harsha Chintalapani <ka...@harsha.io> > > > wrote: > > > > > > In your KIP you added security. provider as rejected alternative and > > > specified "its not the correct way". Do you mind explaining why its not? > > I > > > didn't find any evidence in Java docs to say so. Contrary to your > > statement > > > it does say in the java docs > > > " However, please note that a provider can be used to implement any > > > security service in Java that uses a pluggable architecture with a choice > > > of implementations that fit underneath." > > > > > > Java Security Providers have been used by other projects to provide such > > > integration . I am not sure if you looked into Spiffe project to > > > efficiently distribute certificates but here is an example of Java > > provider > > > > > > https://github.com/spiffe/spiffe-example/blob/master/java-spiffe/ > > > > > spiffe-security-provider/src/main/java/spiffe/api/provider/SpiffeProvider. > > > java which > > > obtains certificates from local daemons. > > > These integrations are being used in Tomcat, Jetty etc.. We are also > > using > > > Security provider to do the same in our Kafka clusters. So unless I see > > > more evidence why security.provider doesn't work for you adding new > > > interfaces while there exists more cleaner way of achieving the goals of > > > this KIP is unnecessary and breaks the well known security interfaces > > > provided by Java itself. > > > > > > Thanks, > > > Harsha > > > > > > On Thu, Aug 08, 2019 at 6:54 AM, Harsha Chintalapani <ka...@harsha.io> > > > wrote: > > > > > > Hi Maulin, > > > Not sure if you looked at my previous replies. This > > > > > > changes > > > > > > are not required as there is already security Provider to do what you are > > > proposing. This KIP https://cwiki.apache.org/confluence/display/KAFKA/ > > > KIP-492%3A+Add+java+security+providers+in+Kafka+Security+config also > > > addresses easy registration of such providers. > > > > > > Thanks, > > > Harsha > > > > > > On Wed, Aug 07, 2019 at 11:31 PM, Maulin Vasavada <maulin.vasavada@gmail. > > > com> wrote: > > > > > > Bump! Can somebody please review this? > > > > > > On Tue, Jul 16, 2019 at 1:51 PM Maulin Vasavada < > > > > > > maulin.vasav...@gmail.com> > > > > > > wrote: > > > > > > Bump! Can somebody please review this? > > > > > > > > >
