kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ismael Juma <ism...@juma.me.uk>
Subject Re: KIP-103: Separation of Internal and External traffic
Date Thu, 05 Jan 2017 00:19:17 GMT
I updated the KIP to cover point 1 as well.

If there are no additional comments, I intend to start a vote thread within
a day or two.

Thanks,
Ismael

On Wed, Jan 4, 2017 at 11:30 PM, Ismael Juma <ismael@juma.me.uk> wrote:

> Thanks for the review Jun. Replies follow.
>
> 1. That's a very good point. Adding a prefix to the JAAS entry name with a
> fallback to the name without the prefix is consistent with how the other
> configs are handled, so I'll update the KIP to mention that.
>
> 2. That was a typo, thanks for catching it. I didn't mean to include
> `listener_security_protocol_map` in `UpdateMetadataRequest` as it's not
> needed (as you said). Fixed.
>
> Ismael
>
> On Wed, Jan 4, 2017 at 10:13 PM, Jun Rao <jun@confluent.io> wrote:
>
>> Hi, Ismael,
>>
>> Thanks for the proposal. Looks good to me overall. Just a couple of minor
>> comments.
>>
>> 1. Sasl also has some properties provided through the login context in the
>> jaas file. Do we want to extend that to allow different login context for
>> different protocol labels on the server side (e.g. Label1KafkaServer,
>> Label2KafkaServer)? This doesn't have to be implemented right away though,
>> as long as we have a plan on how to extend it in the future.
>>
>> 2. In the UpdateMetadataRequest protocol, could you describe what's in
>> listener_security_protocol_map?
>> Also, since we include protocol_label in endpoints, do we really need to
>> include listener_security_protocol_map?
>>
>> Jun
>>
>>
>>
>> On Wed, Jan 4, 2017 at 4:34 AM, Ismael Juma <ismael@juma.me.uk> wrote:
>>
>> > Hi Colin,
>> >
>> > Thanks for the feedback. It's a good question regarding the name
>> `protocol
>> > label`. It was an easy starting name given that the security protocol
>> was
>> > replaced by a label in the listener string. However, I agree that it's
>> > perhaps not as clear as it could be. Maybe `listener key` would be a
>> better
>> > name? It makes it clear that it should be unique in a listeners list and
>> > that it's used to associate a listener to something else (like a
>> security
>> > protocol). Thoughts?
>> >
>> > Ismael
>> >
>> > On Wed, Jan 4, 2017 at 12:29 AM, Colin McCabe <cmccabe@apache.org>
>> wrote:
>> >
>> > > Good idea.  It would be really nice to be able to constrain
>> replication
>> > > traffic to a specific interface or use different security settings.
>> > >
>> > > I'm having a little trouble understanding the "protocol label"
>> concept.
>> > > Clearly protocol labels map to protocols, but they also seem to
>> identify
>> > > particular types of traffic.  Would it be more appropriate to call
>> these
>> > > "traffic types" or "endpoint types"?  Or am I misunderstanding the
>> > > proposal?
>> > >
>> > > cheers,
>> > > Colin
>> > >
>> > >
>> > > On Thu, Dec 22, 2016, at 08:00, Ismael Juma wrote:
>> > > > I've updated the KIP to:
>> > > >
>> > > > 1. Include the ability to set different security configs depending
>> on
>> > the
>> > > > protocol label.
>> > > > 2. Include the mapping from protocol label to security protocol in
>> ZK
>> > and
>> > > > UpdateMetadataRequest.
>> > > > 3. More items in the "Rejected Alternatives" section.
>> > > > 4. Take into account old ZooKeeper-based consumers.
>> > > >
>> > > > Feedback is appreciated as always.
>> > > >
>> > > > I'm particularly interested in people's opinions on the config
>> format
>> > as
>> > > > I
>> > > > am still unsure when it comes to the proposed format versus the
>> first
>> > > > rejected alternative.
>> > > >
>> > > > Ismael
>> > > >
>> > > > On Wed, Dec 21, 2016 at 11:37 PM, Ismael Juma <ismael@juma.me.uk>
>> > wrote:
>> > > >
>> > > > > Thanks Rajini.
>> > > > >
>> > > > > I agree that it's worth thinking about what a fully configurable
>> > label
>> > > > > would look like. I'll update the KIP.
>> > > > >
>> > > > > Ismael
>> > > > >
>> > > > > On 21 Dec 2016 10:53 pm, "Rajini Sivaram" <
>> rajinisivaram@gmail.com>
>> > > wrote:
>> > > > >
>> > > > > Hi Ismael,
>> > > > >
>> > > > > Thank you for the KIP. This is a very useful change.
>> > > > >
>> > > > > Once you allow multiple interfaces with the same security
>> protocol,
>> > you
>> > > > > will soon also need to be able to configure protocol-specific
>> > > properties
>> > > > > for each of the interfaces. To use SSL on internal and external
>> > > networks,
>> > > > > you would almost definitely want different keystores with
>> different
>> > > > > hostname/IP addresses. Similarly for SASL, you might want to
>> enable
>> > > > > different mechanisms, use a different authentication server etc.
>> This
>> > > is
>> > > > > listed under future work.But it may be worth thinking about what
a
>> > > fully
>> > > > > configurable 'label' looks like. Would every property now become
a
>> > > list/map
>> > > > > like listeners - you would then end up with maps of lists for
some
>> > > > > properties. It will good if all properties corresponding to a
>> label
>> > > > > including listener and advertised.listener are configured
>> > consistently
>> > > - if
>> > > > > that is possible,
>> > > > >
>> > > > >
>> > > > > On Wed, Dec 21, 2016 at 8:56 PM, Ismael Juma <ismael@juma.me.uk>
>> > > wrote:
>> > > > >
>> > > > > > Hi all,
>> > > > > >
>> > > > > > We've posted "KIP-103: Separation of Internal and External
>> traffic"
>> > > for
>> > > > > > discussion:
>> > > > > >
>> > > > > > *https://cwiki.apache.org/confluence/display/KAFKA/KIP-
>> > > > > > 103%3A+Separation+of+Internal+and+External+traffic
>> > > > > > <https://cwiki.apache.org/confluence/display/KAFKA/KIP-
>> > > > > > 103%3A+Separation+of+Internal+and+External+traffic>*
>> > > > > >
>> > > > > > Please take a look. Your feedback is appreciated.
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Ismael
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message