Hi Harsha Let me try to write samples and will let you know.
Thanks Maulin On Thu, Aug 8, 2019 at 4:00 PM Harsha Ch <harsha...@gmail.com> wrote: > Hi Maulin, > With java security providers can be as custom you would like it to > be. If you only want to to implement a custom way of loading the > keystore and truststore and not implement any protocol/encryption handling > you can leave them empty and no need to implement. > Have you looked into the links I pasted before? > > https://github.com/spiffe/spiffe-example/blob/master/java-spiffe/spiffe-security-provider/src/main/java/spiffe/api/provider/SpiffeKeyStore.java > > https://github.com/spiffe/spiffe-example/blob/master/java-spiffe/spiffe-security-provider/src/main/java/spiffe/api/provider/SpiffeTrustManager.java > > https://github.com/spiffe/spiffe-example/blob/master/java-spiffe/spiffe-security-provider/src/main/java/spiffe/api/provider/SpiffeProvider.java > > Can you please tell me which methods are too complex in above to implement > or unnecessary? You are changing anything in SSL/TLS implementations > provided by > > All of the implementations delegating the checks to the default > implementation anyway. > Spire agent is an example, its nothing but a GRPC server listening on a > unix domain socket . Above code is making a RPC call to the local daemon to > get the certificate and keys. The mechanics are pretty much same as what > you are asking for. > > Thanks, > Harsha > > 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? > > >> > > > >> > > > >> > > > > > >
