rable or not.
>
> -Original Message-
> From: Pellerin, Clement
> Sent: Monday, September 9, 2019 8:28 PM
> To: dev@kafka.apache.org
> Subject: RE: [DISCUSS] KIP-486 Support for pluggable KeyStore and
> TrustStore
>
> This is a good start.
>
> Please docu
Please specify in the KIP if the new config is reconfigurable or not.
-Original Message-
From: Pellerin, Clement
Sent: Monday, September 9, 2019 8:28 PM
To: dev@kafka.apache.org
Subject: RE: [DISCUSS] KIP-486 Support for pluggable KeyStore and TrustStore
This is a good start.
Please
n Vasavada [mailto:maulin.vasav...@gmail.com]
Sent: Monday, September 9, 2019 6:41 PM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-486 Support for pluggable KeyStore and TrustStore
Hi all
I created a KIP-519 for pluggability of SSLContext/Engine object. Looking
forward for a great discussion and feedback o
First you have to find a complete solution, then you need to document
>> > > it in a KIP and that KIP needs to pass a vote. Any votes before the
>> KIP
>> > > vote starts is meaningless.
>> > >
>> > > As for the ownership and authorship of the KIPs
way it is. I would prefer if
> you
> > > would update your KIP or maybe create a new one. We can mark KIP-383
> as
> > > obsolete after your KIP passes its vote.
> > >
> > > -Original Message-
> > > From: Maulin Vasavada [mailto:maulin.vasav...@gma
obsolete after your KIP passes its vote.
> >
> > -----Original Message-----
> > From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
> > Sent: Friday, September 6, 2019 2:36 AM
> > To: dev@kafka.apache.org
> > Subject: Re: [DISCUSS] KIP-486 Support for pluggable KeyS
Sent: Friday, September 6, 2019 2:36 AM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-486 Support for pluggable KeyStore and TrustStore
>
> Hi all
>
> Any input on my last question about the process?
>
> Also, I have updated the code based on the feedback so far at:
riday, September 6, 2019 2:36 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-486 Support for pluggable KeyStore and TrustStore
Hi all
Any input on my last question about the process?
Also, I have updated the code based on the feedback so far at:
https://github.com/maulin-vasavada/kafka/pull/2/
Hi all
Any input on my last question about the process?
Also, I have updated the code based on the feedback so far at:
https://github.com/maulin-vasavada/kafka/pull/2/files. Still have to figure
out how to plug keys/certs loading while using DefaultSslEngineFactory's
implementation (still need to
Hi all
It seems we are in some sort of agreement so far apart from code
review/comments. However, I have a fundamental question - going forward how
this work from the process standpoint? What do we do with this KIP-486 vs
KIP-383? I feel that both needs to come together since in order to make
Plug
Do you guys think it would be easier if you can provide comments on GitHub
and we can continue there and summarize the conclusion here?
We should not lose addressing any comments.
On Wed, Sep 4, 2019 at 12:34 PM Pellerin, Clement
wrote:
> The proposed interface does not look like the Builder pa
The proposed interface does not look like the Builder pattern I am used to.
Should SslEngineBuilder be called SslEngineFactory instead?
On Mon, Sep 2, 2019, at 03:33, Rajini Sivaram wrote:
> I would expect SslEngineBuilder interface to look something like this,
> perhaps with some tweaking:
>
> p
> > > > inclined toward what Celement is suggesting - having pluggable
> > > SslFactory.
> > > > >
> > > > > Let me do this - let me refactor SslFactory and SslEngineBuilder
> and
> > > review
> > > > > what I can come up with you
t; > > > Maulin
> > > >
> > > > On Fri, Aug 30, 2019 at 12:25 PM Pellerin, Clement <
> > > > clement_pelle...@ibi.com>
> > > > wrote:
> > > >
> > > > > What is your solution to the objection that killed the second
&g
o the objection that killed the second
> iteration
> > > of
> > > > KIP-383?
> > > > Mainly, how do you support validation of reconfiguration requests
> that
> > > > involve new custom properties implemented by the pluggable factory?
> > > > Custom
y the pluggable factory?
> > > Custom properties do not exist yet, but that is very legitimate thing to
> > > design for the future.
> > >
> > > That's why I favor a pluggable SslFactory instead of an SslEngineBuilder
> > > factory.
> > >
>
is very legitimate thing to
> > design for the future.
> >
> > That's why I favor a pluggable SslFactory instead of an SslEngineBuilder
> > factory.
> >
> > -Original Message-
> > From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
> &g
ory instead of an SslEngineBuilder
> factory.
>
> -Original Message-
> From: Maulin Vasavada [mailto:maulin.vasav...@gmail.com]
> Sent: Friday, August 30, 2019 3:07 PM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-486 Support for pluggable KeyStore and
>
add
>> > > >> validation of custom properties in a future KIP. The solution to
>> that is
>> > > >> the first proposal I wrote for KIP-383 which made the whole
>> SslFactory
>> > > >> pluggable. That first solution was also vetoed hence th
On Thu, Aug 29, 2019 at 12:47 PM Pellerin, Clement <
> >> > > > clement_pelle...@ibi.com> wrote:
> >> > > >
> >> > > >> KIP-383 in its present form was vetoed because it was not possible
> >> to
> >> > > add
>
ation of custom properties in a future KIP. The solution to
>> that is
>> > > >> the first proposal I wrote for KIP-383 which made the whole
>> SslFactory
>> > > >> pluggable. That first solution was also vetoed hence the deadlock.
>> > > >&g
ution to
> that is
> > > >> the first proposal I wrote for KIP-383 which made the whole
> SslFactory
> > > >> pluggable. That first solution was also vetoed hence the deadlock.
> > > >>
> > > >> Replacing the whole factory was a much n
t was vetoed
> > >> because doing this almost invariably meant the replacement lost all the
> > >> complex validation code in the default SslFactory.
> > >>
> > >> My current idea is to extract the validation code into another public
> > API
&
d call. I did not look at the newly refactored code
> and
> >> I did not study how to do this yet. KIP-383 was not popular at the time
> and
> >> designing a new solution is a lot of work.
> >>
> >> Is there interest from 3 binding voters for something like th
is a lot of work.
>>
>> Is there interest from 3 binding voters for something like this?
>>
>> -----Original Message-
>> From: Rajini Sivaram [mailto:rajinisiva...@gmail.com]
>> Sent: Thursday, August 29, 2019 2:57 PM
>> To: dev
>> Subject: Re
; Is there interest from 3 binding voters for something like this?
>
> -Original Message-
> From: Rajini Sivaram [mailto:rajinisiva...@gmail.com]
> Sent: Thursday, August 29, 2019 2:57 PM
> To: dev
> Subject: Re: [DISCUSS] KIP-486 Support for pluggable KeyStore and
> TrustSto
...@gmail.com]
Sent: Thursday, August 29, 2019 2:57 PM
To: dev
Subject: Re: [DISCUSS] KIP-486 Support for pluggable KeyStore and TrustStore
Hi Maulin,
In SSL scenarios, I imagine security providers introduced by KIP-492 are
likely to be most useful when you want to use third party providers. The
biggest
Hi Maulin,
In SSL scenarios, I imagine security providers introduced by KIP-492 are
likely to be most useful when you want to use third party providers. The
biggest advantage of the config from that KIP is that you don't need to
write much code to integrate existing security providers into Kafka b
Hi Harsha
Thank you. Appreciate your time and support on this. Let me go back do some
more research and get back to you on the KeyStore interface part.
Basically, if we return certs and keys in the interface then Kafka code
will have to build KeyStore object - which is also reasonable.
Thanks
Mau
Hi Maulin,
Use cases are clear now. I am +1 for moving forward
with the discussions on having such configurable option for users. But the
interfaces is proposed doesn't look right to me. We are still talking about
keystore interfaces. Given keystore's are used as filebased way
t;> >
> >>>> > it to
> >>>> > be. If you only want to to implement a custom way of loading the
> >>>> >
> >>>> > keystore
> >>>> >
> >>>> > and truststore and not implement any protocol/en
/main/java/spiffe/api/provider/SpiffeProvider.
>>>> >
>>>> > java
>>>> >
>>>> > Can you please tell me which methods are too complex in above to
>>>> >
>>>> > implement
>>>> >
>>>> >
Hi Harsha
As we synced-up offline on this topic, we hope you don't have any more
clarifications that you are seeking. If that is the case, can you please
help us move this forward and discuss what changes you would expect on the
KIP design in order to make it valuable contribution?
Just FYI - we
Hi Harsha
Any response on my question? I feel this KIP is worth accommodating. Your
help is much appreciated.
Thanks
Maulin
On Tue, Aug 20, 2019 at 11:52 PM Maulin Vasavada
wrote:
> Hi Harsha
>
> I've examined the SPIFFE provider more and have one question -
>
> If SPIFFE didn't have a need to
Hi Harsha
I've examined the SPIFFE provider more and have one question -
If SPIFFE didn't have a need to do checkSpiffeId() call at the below
location, would you really still write the Provider? *OR*
Would you just use TrustManagerFactory.init(KeyStore) signature to pass the
KeyStore from set of
Maulin,
The code parts you are pointing are specific for Spiffe and if
you are talking about validate method which uses PKIX check like any
other provider does.
If you want to default to SunJSSE everywhere you can do so by delegating
the calls in these methods to SunJSSE provider.
T
Okay, so I take that you guys agree that I have to write a 'custom'
algorithm and a provider to make it work , correct?
Now, for Harsha's comment "Here the 'Custom' Algorithm is not an
implementation per say , ..." , I diagree. You can refer to
https://github.com/spiffe/java-spiffe/blob/master/src
Hi Maulin, thanks for the discussion. As Harsha pointed out, to use the
KIP492, you need to create a new provider, register a *new* custom
algorithm for your keymanager and trustmanager factory implementations.
After this, the kafka server configuration can be done as given below
# Register the pr
Answers are in-line
On Mon, Aug 19, 2019 at 10:45 PM, Maulin Vasavada wrote:
> Hi Colin
>
>
> When I refer to "standard" or "custom" algorithms I am following Java
> security Provider Terminology. You can refer to
> https://docs.oracle.com/javase/7/docs/technotes/guides/security/
> StandardNam
Instead of keep diverging in different directions, it would be helpful if
you guys take my detailed posts with 1st to 4th points I mentioned and
start referring/commenting on each of those if you agree with them or not.
On Mon, Aug 19, 2019 at 10:45 PM Maulin Vasavada
wrote:
> Hi Colin
>
> When
Hi Colin
When I refer to "standard" or "custom" algorithms I am following Java
security Provider Terminology. You can refer to
https://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#TrustManagerFactory
link I provided earlier in the emails. It says PKIX is the default
A
Hi Maulin,
A lot of JSSE providers don't implement custom algorithms. Spire is a good
example of a JSSE provider that doesn't, and yet is still useful to many
people. Your JSSE provider can work fine even if it doesn't implement a custom
algorithm.
Maybe I'm missing something, but I don't un
On top of everything above I feel strongly to add the 4th point which is
based on Java APIs for TrustManagerFactory.init(KeyStore) (
https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/TrustManagerFactory.html#init(java.security.KeyStore))
and KeyManagerFactory.init(KeyStore, char[]) (
https://
Hi Harsha/Colin
I did the sample with a custom Provider for TrustStoreManager and tried
using ssl.provider Kafka config AND the way KIP-492 is suggesting (by
adding Provider programmatically instead of relying on
ssl.provider+java.security. The below sample is followed by my detailed
findings. I'l
Just to update - still working on it. Get to work only on and off on it :(
On Thu, Aug 8, 2019 at 4:05 PM Maulin Vasavada
wrote:
> 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 wrote:
>
>> Hi Maulin,
>>
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 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 an
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
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
In
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.
Go
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 pro
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
Hi Maulin,
On Thu, Aug 08, 2019 at 2:04 PM, Maulin Vasavada
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 req
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.
The ask here is different than KIP-492. We don't have any need to
modify/specify the algorithm parameter. Doe
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
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
Bump! Can somebody please review this?
On Tue, Jul 16, 2019 at 1:51 PM Maulin Vasavada
wrote:
> Bump! Can somebody please review this?
>
You can look at the implementation here for an example
https://github.com/spiffe/spiffe-example/blob/master/java-spiffe/spiffe-security-provider/src/main/java/spiffe/api/provider/SpiffeProvider.java
On Tue, Jul 16, 2019, at 9:00 PM, Harsha wrote:
> Hi Maulin,
>This is not require
Hi Maulin,
This is not required. We are already addressing this. One can
write a KeyStoreProvider and TrustStoreProvider. Please look at this JIRA
https://issues.apache.org/jira/browse/KAFKA-8191 . It allows users to add
custom security provider in which you can write KeyManagerFa
Bump! Can somebody please review this?
59 matches
Mail list logo
