From: Sriharsha Chintalapani ka...@harsha.io
Sent: Tuesday, April 28, 2015 4:31 PM
To: dev@kafka.apache.org
Cc: Haohui Mai
Subject: Re: [DISCUSS] KIP-12 - Kafka Sasl/Kerberos implementation
Updated KIP-12 is here
https://cwiki.apache.org
From: Sriharsha Chintalapani ka...@harsha.io
Sent: Tuesday, April 28, 2015 4:31 PM
To: dev@kafka.apache.org
Cc: Haohui Mai
Subject: Re: [DISCUSS] KIP-12 - Kafka Sasl/Kerberos implementation
Updated KIP-12 is here
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId
: Haohui Mai
Subject: Re: [DISCUSS] KIP-12 - Kafka Sasl/Kerberos implementation
Updated KIP-12 is here
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=51809888
. My new proposal talks about Channel having two layers one is
TransportLayer and another Authentication Layer
Chintalapani ka...@harsha.io
Sent: Tuesday, April 28, 2015 4:31 PM
To: dev@kafka.apache.org
Cc: Haohui Mai
Subject: Re: [DISCUSS] KIP-12 - Kafka Sasl/Kerberos implementation
Updated KIP-12 is here
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=51809888
. My new
-12 - Kafka Sasl/Kerberos implementation
Updated KIP-12 is here
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=51809888 . My
new proposal talks about Channel having two layers one is TransportLayer and
another Authentication Layer.
If users want to do authentication without
Subject: Re: [DISCUSS] KIP-12 - Kafka Sasl/Kerberos implementation
Updated KIP-12 is here
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=51809888 . My
new proposal talks about Channel having two layers one is TransportLayer and
another Authentication Layer.
If users want to do
Updated KIP-12 is here
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=51809888 . My
new proposal talks about Channel having two layers one is TransportLayer and
another Authentication Layer.
If users want to do authentication without encryption they can use
Have there been any discussions around separating out authentication and
encryption protocols for Kafka endpoints to enable different combinations?
In our deployment environment, we would like to use TLS for encryption, but
we don't necessarily want to use certificate-based authentication of
Harsha,
Thank you for the quick response. (Sorry had missed sending this reply to
the dev-list earlier)..
1. I am not sure what the new server-side code is going to look like
after refactoring under KAFKA-1928. But I was assuming that there would be
only one Channel implementation
Rajini,
I am exploring this part right now. To support PLAINTEXT and SSL as
protocols and Kerberos auth as authentication on top of plaintext or ssl (if
users want to do encryption over an auth mechanism). This is mainly influenced
by SASL or GSS-API performance issue when I enable
Thank you, Harsha. Yes, that makes sense. Shall take a look when the KIP is
finalized.
Rajini
On Fri, Apr 24, 2015 at 2:34 PM, Sriharsha Chintalapani ka...@harsha.io
wrote:
Rajini,
I am exploring this part right now. To support PLAINTEXT and SSL
as protocols and Kerberos auth as
Hi Gari,
I apologize for not clear in KIP and starting discussion thread earlier.
My initial proposal( currently in KIP ) to provide PLAINTEXT, SSL and KERBEROS
as individual protocol implementation.
As you mentioned at the end
“In terms of message level integrity and confidentiality
Sorry for jumping in late, but I have been trying to follow this chain as
well as the updates to the KIP. I don't mean to seem critical and I may be
misunderstanding the proposed implementation, but there seems to be some
confusion around terminology (at least from my perspective) and I am not
I yet to update the KIP with my latest proposal. So give me few days to update
it.
I am looking at supporting KERBEROS for the first release and going to use JAAS
Login Modules to provide authentication.
And will we provide a default SASL PLAIN mechanism on the server side
Yes . I’ll update
Great. Sounds good. I'll re-read the KIP ASAP.
Is their another KIP around authentication providers or is that being
tracked here as well. For example, the SASL PLAIN mechanism carries a
username and password but currently I don't know where that would be
authenticated? I notice that
Hi Rajini,
Thanks for the details. I did go through your code . There was a
discussion before about not having selector related code into the channel or
extending the selector it self.
1. *Support for running potentially long-running delegated tasks outside
the network thread*: It is
1. *Support for running potentially long-running delegated tasks outside
the network thread*: It is recommended that delegated tasks indicated by
a handshake status of NEED_TASK are run on a separate thread since they may
block (
When we were working on the client-side SSL implementation for Kafka, we
found that returning selection interest from handshake() method wasn't
sufficient to handle some of the SSL sequences. We resorted to managing the
selection key and interest state within SSLChannel to avoid SSL-specific
Hey Sriharsha,
Thanks for the excellent write-up.
Couple of minor questions:
1. Isn't the blocking handshake going to be a performance concern? Can we
do the handshake non-blocking instead? If anything that causes connections
to drop can incur blocking network roundtrips won't that eat up all
Hi Jay,
Thanks for the review.
1. Isn't the blocking handshake going to be a performance concern? Can we
do the handshake non-blocking instead? If anything that causes connections
to drop can incur blocking network roundtrips won't that eat up all the
network threads immediately? I
Hi Jun,
I am using the underlying protocol GSS-API that sasl also uses. I
can add details about LDAP/AD . For AD , this is in general the integration of
AD to KERBEROS. I.e kerberos can talk to AD to get the kinit login
credentials ( more of a setup details between kerberos and AD)
Hi,
I updated the KIP-12 with more details. Please take a look
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=51809888
Thanks,
Harsha
On February 11, 2015 at 10:02:43 AM, Harsha (ka...@harsha.io) wrote:
Thanks Joe. It will be part of KafkaServer and will run on its own
Hi, Harsha,
For SASL, a common use case is the integration with LDAP/AD. For
completeness, could you describe (or provide a link) how such integration
can be done?
Also, what about the SSL support, do you plan to describe it in same same
KIP or a separate one?
Thanks,
Jun
On Mon, Apr 20, 2015
Hi,
Here is the initial proposal for sasl/kerberos implementation for
kafka https://cwiki.apache.org/confluence/x/YI4WAw
and JIRA https://issues.apache.org/jira/browse/KAFKA-1686. I am
currently working on prototype which will add more details to the KIP.
Just opening the thread to say
Hi,
Here is the initial proposal for sasl/kerberos implementation for
kafka https://cwiki.apache.org/confluence/x/YI4WAw
and JIRA https://issues.apache.org/jira/browse/KAFKA-1686. I am
currently working on prototype which will add more details to the KIP.
Just opening the thread to say
Thanks Harsha, looks good so far. How were you thinking of running
the KerberosTicketManager as a standalone process or like controller or is
it a layer of code that does the plumbing pieces everywhere?
~ Joestein
On Wed, Feb 11, 2015 at 12:18 PM, Harsha ka...@harsha.io wrote:
Hi,
Here is
Looks good. Thanks for working on this.
One note, the Channel implementation from SSL only works on Java7 and up.
Since we are still supporting Java 6, I'm working on a lighter wrapper that
will be a composite on SocketChannel but will not extend it. Perhaps you'll
want to use that.
Looking
27 matches
Mail list logo
