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