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? >> > >> > >> >
