Hi Colin, To your point - "Also, it seems like most people who want a custom truststore / keystore will also want a custom SSL provider," I don't think so. Take our own example. We have a fairly large Kafka eco-system (500B+ messages a day flowing through with poly-glot client-base) with strict InfoSec requirements but we still do not need Custom SSL Provider for Kafka.
Thanks Maulin On Thu, Aug 8, 2019 at 3:47 PM Maulin Vasavada <maulin.vasav...@gmail.com> wrote: > Imagine a scenario like - We know we have a custom KMS and as a Kafka > owner we want to comply to using that KMS source to load keys/certs. As a > Kafka owner we know how to integrate with KMS but doesn't necessarily have > to know anything about cipher suites, algorithms, and SSL/TLS > implementation. Going the Provider way requires to know lot more than we > should, isn't it? Not that we would have concern/shy-away knowing those > details - but if we don't have to - why should we? > > On Thu, Aug 8, 2019 at 3:23 PM Maulin Vasavada <maulin.vasav...@gmail.com> > 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? >>> > >>> > >>> >>
