You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Jeff Holoman <jh...@cloudera.com> on 2015/03/03 21:44:25 UTC
[VOTE] KIP-7 Security - IP Filtering
Details in the wiki.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+Filtering
--
Jeff Holoman
Systems Engineer
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Parth Brahmbhatt <pb...@hortonworks.com>.
I can confirm that KAFKA-1688 will cover this use case. Please go over
https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+In
terface and let me know if you think there is a different use case being
covered by KIP-7.
Thanks
Parth
On 3/20/15, 9:26 AM, "Jun Rao" <ju...@confluent.io> wrote:
>Yes, we can discuss the implementation separately.
>
>As for the proposal itself, have you looked at KAFKA-1688? Could this just
>be a special case for authorization and be included there?
>
>Thanks,
>
>Jun
>
>On Wed, Mar 18, 2015 at 6:26 PM, Jeff Holoman <jh...@cloudera.com>
>wrote:
>
>> One other thought. Does the timing of the implementation (or lack
>>thereof)
>> affect the proposal? It seems like the question you are asking is an
>> implementation detail in terms of when the work would be done. If there
>> isn't really support for the KIP that's ok, just wanting to make sure we
>> are segmenting the vote for the KIP from concerns about implementation
>> timing.
>>
>> Thanks!
>>
>> Jeff
>>
>> On Wed, Mar 18, 2015 at 9:22 PM, Jeff Holoman <jh...@cloudera.com>
>> wrote:
>>
>> > Hey Jun thanks for the comment.
>> >
>> > Is the plan to re-factor the SocketServer implementation
>>significantly?
>> > The current check is just in the acceptor. Does this change with the
>> > refactor?
>> >
>> > Thanks
>> >
>> > Jeff
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <ju...@confluent.io> wrote:
>> >
>> >> The proposal sounds reasonable. Timing wise, since we plan to
>>refactor
>> the
>> >> network layer code in the broker, perhaps this can wait until
>>KAFKA-1928
>> >> is
>> >> done?
>> >>
>> >> Thanks,
>> >>
>> >> Jun
>> >>
>> >> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman <jh...@cloudera.com>
>> >> wrote:
>> >>
>> >> > bump
>> >> >
>> >> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman
>><jh...@cloudera.com>
>> >> > wrote:
>> >> >
>> >> > > Guozhang,
>> >> > >
>> >> > > The way the patch is implemented, the check is done in the
>>acceptor
>> >> > thread
>> >> > > accept() method of the Socket Server, just before
>>connectionQuotas.
>> >> > >
>> >> > > Thanks
>> >> > >
>> >> > > Jeff
>> >> > >
>> >> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang
>><wa...@gmail.com>
>> >> > wrote:
>> >> > >
>> >> > >> Jeff,
>> >> > >>
>> >> > >> I am wondering if the IP filtering rule can be enforced at the
>> socket
>> >> > >> server level instead of the Kafka API level?
>> >> > >>
>> >> > >> Guozhang
>> >> > >>
>> >> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin
>> >> <jqin@linkedin.com.invalid
>> >> > >
>> >> > >> wrote:
>> >> > >>
>> >> > >> > +1 (non-binding)
>> >> > >> >
>> >> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com>
>> wrote:
>> >> > >> >
>> >> > >> > >+1 (non-binding)
>> >> > >> > >
>> >> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <
>> >> jholoman@cloudera.com
>> >> > >
>> >> > >> > >wrote:
>> >> > >> > >> Details in the wiki.
>> >> > >> > >>
>> >> > >> > >>
>> >> > >> > >>
>> >> > >> > >>
>> >> > >> >
>> >> > >>
>> >> >
>> >>
>>
>>https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
>> >> > >> > >>iltering
>> >> > >> > >>
>> >> > >> > >>
>> >> > >> > >>
>> >> > >> > >> --
>> >> > >> > >> Jeff Holoman
>> >> > >> > >> Systems Engineer
>> >> > >> >
>> >> > >> >
>> >> > >>
>> >> > >>
>> >> > >> --
>> >> > >> -- Guozhang
>> >> > >>
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Jeff Holoman
>> >> > > Systems Engineer
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > Jeff Holoman
>> >> > Systems Engineer
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Jeff Holoman
>> > Systems Engineer
>> >
>> >
>> >
>> >
>>
>>
>> --
>> Jeff Holoman
>> Systems Engineer
>>
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Brock Noland <br...@apache.org>.
I think it is acceptable for KIP-11 to allow additional network based
authorization. However I do feel that most user will want something
simpler and thus I don't feel KIP-11 should require network based
authorization by default.
For example postgres allows something similar to what is being
discussed here. In addition to user based authz of database objects,
administrators can use the "pg_hba.conf" configuration file to perform
network based authz for users and groups.
Despite this, few postgres installs with more than one user, use the
"pg_hba.conf" configuration for user based network authz. They do,
however, use standard user based authz for database objects and
"pg_hba.conf" for basic database-wide network authz.
tl;dr - I think we should implement both KIP-7 and KIP-11.
On Fri, Mar 20, 2015 at 7:23 PM, Gwen Shapira <gs...@cloudera.com> wrote:
> I'd like to add that HDFS has had ACLs + RBAC + global IP white/black list
> for years now.
>
> We did not notice any customers confusing the features. I've seen customers
> use each feature for different purposes.
>
> Actually, the only system I am aware of that integrated IP access controls
> together with RBAC and ACLs is MySQL, where it leads to major confusion
> among new admins (I can log in as "gwenshap" from a remote machine but not
> from localhost or vice-versa...).
>
> Gwen
>
> On Fri, Mar 20, 2015 at 4:04 PM, Jeff Holoman <jh...@cloudera.com> wrote:
>
>> Parth,
>>
>> I think it's important to understand the timing of both the initial JIRA
>> and the KIP, it helps put my comments in proper context.
>>
>> The initial JIRA for this was created back in December, so the timeline for
>> 1688/KIP-11 was pretty unclear. KIP-7 came out when we started doing KIPs,
>> back in Jan. The initial comments I think pretty clearly acknowledged the
>> work on 1688.
>>
>> My comment re: integration was that perhaps the check logic could be reused
>> (i.e, the CIDR range checks). That's what I meant when I mentioned "the
>> intent". At that point there was no KIP-11 and no patch, so it was just a
>> hunch.
>>
>> In terms of it being a different use case, I do think there are some
>> aspects which would be beneficial, even given the work on 1688.
>>
>> 1) Simplicity
>> 2) Less config - 2 params
>> 3) Allows for both whitelisting and blacklisting, giving a bit more
>> flexibility.
>>
>> Another key driver, at least at the time, was timing. As this discussion
>> has been extended that becomes less of a motivator, which I understand.
>>
>> I don't necessarily think that giving users options to limit access will
>> confuse them, given the new interface for security will likely take a bit
>> of understanding to implement correctly. In fact they might be quite
>> complimentary.
>>
>> Lets take the 2nd example in KIP 11:
>>
>> user2.hosts=*
>> user2.operation=read
>>
>> So if I understand correctly, this would allow read access for a particular
>> topic from any host for a given user. it could be helpful to block a range
>> of IPs (like production or QA) but otherwise not specify every potential
>> host that needs to read from that topic.
>>
>> As you mentioned adding additional constructs make the ACL's a bit more
>> complex, maybe this provides some relief there.
>>
>> Jun, if folks feel like there's too much overlap, and this wouldn't be
>> useful, then that's fair. That's what the votes are for right? :)
>>
>>
>> Thanks
>>
>> Jeff
>>
>>
>> On Fri, Mar 20, 2015 at 6:01 PM, Parth Brahmbhatt <
>> pbrahmbhatt@hortonworks.com> wrote:
>>
>> > I am guessing in your last reply you meant KIP-11. And yes, I think
>> KIP-11
>> > subsumed KIP-7 so if we can finish KIP-11 we should not need KIP=7 but I
>> > will let Jeff confirm that,
>> >
>> > Thanks
>> > Parth
>> >
>> >
>> > On 3/20/15, 2:32 PM, "Jun Rao" <ju...@confluent.io> wrote:
>> >
>> > >Right, if this KIP is subsumed by KIP-7, perhaps we just need to wait
>> > >until
>> > >KIP-7 is done? If we add the small change now, we will have to worry
>> about
>> > >migrating existing users and deprecating some configs when KIP-7 is
>> done.
>> > >
>> > >Thanks,
>> > >
>> > >Jun
>> > >
>> > >On Fri, Mar 20, 2015 at 10:36 AM, Parth Brahmbhatt <
>> > >pbrahmbhatt@hortonworks.com> wrote:
>> > >
>> > >> I am not entirely sure what you mean by integrating KIP-7 work with
>> > >> KAFKA-1688. Wouldn¹t the work done as part of KIP-7 become obsolete
>> once
>> > >> KAFKA-1688 is done? Multiple ways of controlling these authorization
>> > >>just
>> > >> seems extra configuration that will confuse admins/users.
>> > >>
>> > >> If timing is the only issue don¹t you think its better to focus our
>> > >>energy
>> > >> on getting 1688 done faster which seem to be the longer term goal
>> > >>anyways?
>> > >>
>> > >> Thanks
>> > >> Parth
>> > >>
>> > >> On 3/20/15, 10:28 AM, "Jeff Holoman" <jh...@cloudera.com> wrote:
>> > >>
>> > >> >Hey Jun,
>> > >> >
>> > >> >The intent was for the same functionality to be utilized when 1688 is
>> > >> >done,
>> > >> >as mentioned in the KIP:
>> > >> >
>> > >> >"The broader security initiative <http://kafka-1682/> will add more
>> > >> robust
>> > >> >controls for these types of environments, and this proposal could be
>> > >> >integrated with that work at the appropriate time. This is also the
>> > >> >specific request of a large financial services company."
>> > >> >
>> > >> >I don't think including the functionality now (as it's relatively
>> > >>simple)
>> > >> >would preclude integration into 1688. At that point the
>> implementation
>> > >>of
>> > >> >the check might change, but as it's a broker config, there shouldn't
>> be
>> > >> >concerns about backward compatibility.
>> > >> >
>> > >> >Hope that helps
>> > >> >
>> > >> >Thanks
>> > >> >
>> > >> >Jeff
>> > >> >
>> > >> >On Fri, Mar 20, 2015 at 12:26 PM, Jun Rao <ju...@confluent.io> wrote:
>> > >> >
>> > >> >> Yes, we can discuss the implementation separately.
>> > >> >>
>> > >> >> As for the proposal itself, have you looked at KAFKA-1688? Could
>> this
>> > >> >>just
>> > >> >> be a special case for authorization and be included there?
>> > >> >>
>> > >> >> Thanks,
>> > >> >>
>> > >> >> Jun
>> > >> >>
>> > >> >> On Wed, Mar 18, 2015 at 6:26 PM, Jeff Holoman <
>> jholoman@cloudera.com
>> > >
>> > >> >> wrote:
>> > >> >>
>> > >> >> > One other thought. Does the timing of the implementation (or lack
>> > >> >> thereof)
>> > >> >> > affect the proposal? It seems like the question you are asking is
>> > >>an
>> > >> >> > implementation detail in terms of when the work would be done. If
>> > >> >>there
>> > >> >> > isn't really support for the KIP that's ok, just wanting to make
>> > >>sure
>> > >> >>we
>> > >> >> > are segmenting the vote for the KIP from concerns about
>> > >>implementation
>> > >> >> > timing.
>> > >> >> >
>> > >> >> > Thanks!
>> > >> >> >
>> > >> >> > Jeff
>> > >> >> >
>> > >> >> > On Wed, Mar 18, 2015 at 9:22 PM, Jeff Holoman
>> > >><jh...@cloudera.com>
>> > >> >> > wrote:
>> > >> >> >
>> > >> >> > > Hey Jun thanks for the comment.
>> > >> >> > >
>> > >> >> > > Is the plan to re-factor the SocketServer implementation
>> > >> >>significantly?
>> > >> >> > > The current check is just in the acceptor. Does this change
>> with
>> > >>the
>> > >> >> > > refactor?
>> > >> >> > >
>> > >> >> > > Thanks
>> > >> >> > >
>> > >> >> > > Jeff
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <ju...@confluent.io>
>> > >>wrote:
>> > >> >> > >
>> > >> >> > >> The proposal sounds reasonable. Timing wise, since we plan to
>> > >> >>refactor
>> > >> >> > the
>> > >> >> > >> network layer code in the broker, perhaps this can wait until
>> > >> >> KAFKA-1928
>> > >> >> > >> is
>> > >> >> > >> done?
>> > >> >> > >>
>> > >> >> > >> Thanks,
>> > >> >> > >>
>> > >> >> > >> Jun
>> > >> >> > >>
>> > >> >> > >> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman
>> > >> >><jh...@cloudera.com>
>> > >> >> > >> wrote:
>> > >> >> > >>
>> > >> >> > >> > bump
>> > >> >> > >> >
>> > >> >> > >> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman
>> > >> >><jholoman@cloudera.com
>> > >> >> >
>> > >> >> > >> > wrote:
>> > >> >> > >> >
>> > >> >> > >> > > Guozhang,
>> > >> >> > >> > >
>> > >> >> > >> > > The way the patch is implemented, the check is done in the
>> > >> >> acceptor
>> > >> >> > >> > thread
>> > >> >> > >> > > accept() method of the Socket Server, just before
>> > >> >> connectionQuotas.
>> > >> >> > >> > >
>> > >> >> > >> > > Thanks
>> > >> >> > >> > >
>> > >> >> > >> > > Jeff
>> > >> >> > >> > >
>> > >> >> > >> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang
>> > >> >><wangguoz@gmail.com
>> > >> >> >
>> > >> >> > >> > wrote:
>> > >> >> > >> > >
>> > >> >> > >> > >> Jeff,
>> > >> >> > >> > >>
>> > >> >> > >> > >> I am wondering if the IP filtering rule can be enforced
>> at
>> > >>the
>> > >> >> > socket
>> > >> >> > >> > >> server level instead of the Kafka API level?
>> > >> >> > >> > >>
>> > >> >> > >> > >> Guozhang
>> > >> >> > >> > >>
>> > >> >> > >> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin
>> > >> >> > >> <jqin@linkedin.com.invalid
>> > >> >> > >> > >
>> > >> >> > >> > >> wrote:
>> > >> >> > >> > >>
>> > >> >> > >> > >> > +1 (non-binding)
>> > >> >> > >> > >> >
>> > >> >> > >> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira"
>> > >><gs...@cloudera.com>
>> > >> >> > wrote:
>> > >> >> > >> > >> >
>> > >> >> > >> > >> > >+1 (non-binding)
>> > >> >> > >> > >> > >
>> > >> >> > >> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <
>> > >> >> > >> jholoman@cloudera.com
>> > >> >> > >> > >
>> > >> >> > >> > >> > >wrote:
>> > >> >> > >> > >> > >> Details in the wiki.
>> > >> >> > >> > >> > >>
>> > >> >> > >> > >> > >>
>> > >> >> > >> > >> > >>
>> > >> >> > >> > >> > >>
>> > >> >> > >> > >> >
>> > >> >> > >> > >>
>> > >> >> > >> >
>> > >> >> > >>
>> > >> >> >
>> > >> >>
>> > >> >>
>> > >>
>> > >>
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
>> > >> >> > >> > >> > >>iltering
>> > >> >> > >> > >> > >>
>> > >> >> > >> > >> > >>
>> > >> >> > >> > >> > >>
>> > >> >> > >> > >> > >> --
>> > >> >> > >> > >> > >> Jeff Holoman
>> > >> >> > >> > >> > >> Systems Engineer
>> > >> >> > >> > >> >
>> > >> >> > >> > >> >
>> > >> >> > >> > >>
>> > >> >> > >> > >>
>> > >> >> > >> > >> --
>> > >> >> > >> > >> -- Guozhang
>> > >> >> > >> > >>
>> > >> >> > >> > >
>> > >> >> > >> > >
>> > >> >> > >> > >
>> > >> >> > >> > > --
>> > >> >> > >> > > Jeff Holoman
>> > >> >> > >> > > Systems Engineer
>> > >> >> > >> > >
>> > >> >> > >> > >
>> > >> >> > >> > >
>> > >> >> > >> > >
>> > >> >> > >> >
>> > >> >> > >> >
>> > >> >> > >> > --
>> > >> >> > >> > Jeff Holoman
>> > >> >> > >> > Systems Engineer
>> > >> >> > >> >
>> > >> >> > >>
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > --
>> > >> >> > > Jeff Holoman
>> > >> >> > > Systems Engineer
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > >
>> > >> >> >
>> > >> >> >
>> > >> >> > --
>> > >> >> > Jeff Holoman
>> > >> >> > Systems Engineer
>> > >> >> >
>> > >> >>
>> > >> >
>> > >> >
>> > >> >
>> > >> >--
>> > >> >Jeff Holoman
>> > >> >Systems Engineer
>> > >>
>> > >>
>> >
>> >
>>
>>
>> --
>> Jeff Holoman
>> Systems Engineer
>>
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Gwen Shapira <gs...@cloudera.com>.
I'd like to add that HDFS has had ACLs + RBAC + global IP white/black list
for years now.
We did not notice any customers confusing the features. I've seen customers
use each feature for different purposes.
Actually, the only system I am aware of that integrated IP access controls
together with RBAC and ACLs is MySQL, where it leads to major confusion
among new admins (I can log in as "gwenshap" from a remote machine but not
from localhost or vice-versa...).
Gwen
On Fri, Mar 20, 2015 at 4:04 PM, Jeff Holoman <jh...@cloudera.com> wrote:
> Parth,
>
> I think it's important to understand the timing of both the initial JIRA
> and the KIP, it helps put my comments in proper context.
>
> The initial JIRA for this was created back in December, so the timeline for
> 1688/KIP-11 was pretty unclear. KIP-7 came out when we started doing KIPs,
> back in Jan. The initial comments I think pretty clearly acknowledged the
> work on 1688.
>
> My comment re: integration was that perhaps the check logic could be reused
> (i.e, the CIDR range checks). That's what I meant when I mentioned "the
> intent". At that point there was no KIP-11 and no patch, so it was just a
> hunch.
>
> In terms of it being a different use case, I do think there are some
> aspects which would be beneficial, even given the work on 1688.
>
> 1) Simplicity
> 2) Less config - 2 params
> 3) Allows for both whitelisting and blacklisting, giving a bit more
> flexibility.
>
> Another key driver, at least at the time, was timing. As this discussion
> has been extended that becomes less of a motivator, which I understand.
>
> I don't necessarily think that giving users options to limit access will
> confuse them, given the new interface for security will likely take a bit
> of understanding to implement correctly. In fact they might be quite
> complimentary.
>
> Lets take the 2nd example in KIP 11:
>
> user2.hosts=*
> user2.operation=read
>
> So if I understand correctly, this would allow read access for a particular
> topic from any host for a given user. it could be helpful to block a range
> of IPs (like production or QA) but otherwise not specify every potential
> host that needs to read from that topic.
>
> As you mentioned adding additional constructs make the ACL's a bit more
> complex, maybe this provides some relief there.
>
> Jun, if folks feel like there's too much overlap, and this wouldn't be
> useful, then that's fair. That's what the votes are for right? :)
>
>
> Thanks
>
> Jeff
>
>
> On Fri, Mar 20, 2015 at 6:01 PM, Parth Brahmbhatt <
> pbrahmbhatt@hortonworks.com> wrote:
>
> > I am guessing in your last reply you meant KIP-11. And yes, I think
> KIP-11
> > subsumed KIP-7 so if we can finish KIP-11 we should not need KIP=7 but I
> > will let Jeff confirm that,
> >
> > Thanks
> > Parth
> >
> >
> > On 3/20/15, 2:32 PM, "Jun Rao" <ju...@confluent.io> wrote:
> >
> > >Right, if this KIP is subsumed by KIP-7, perhaps we just need to wait
> > >until
> > >KIP-7 is done? If we add the small change now, we will have to worry
> about
> > >migrating existing users and deprecating some configs when KIP-7 is
> done.
> > >
> > >Thanks,
> > >
> > >Jun
> > >
> > >On Fri, Mar 20, 2015 at 10:36 AM, Parth Brahmbhatt <
> > >pbrahmbhatt@hortonworks.com> wrote:
> > >
> > >> I am not entirely sure what you mean by integrating KIP-7 work with
> > >> KAFKA-1688. Wouldn¹t the work done as part of KIP-7 become obsolete
> once
> > >> KAFKA-1688 is done? Multiple ways of controlling these authorization
> > >>just
> > >> seems extra configuration that will confuse admins/users.
> > >>
> > >> If timing is the only issue don¹t you think its better to focus our
> > >>energy
> > >> on getting 1688 done faster which seem to be the longer term goal
> > >>anyways?
> > >>
> > >> Thanks
> > >> Parth
> > >>
> > >> On 3/20/15, 10:28 AM, "Jeff Holoman" <jh...@cloudera.com> wrote:
> > >>
> > >> >Hey Jun,
> > >> >
> > >> >The intent was for the same functionality to be utilized when 1688 is
> > >> >done,
> > >> >as mentioned in the KIP:
> > >> >
> > >> >"The broader security initiative <http://kafka-1682/> will add more
> > >> robust
> > >> >controls for these types of environments, and this proposal could be
> > >> >integrated with that work at the appropriate time. This is also the
> > >> >specific request of a large financial services company."
> > >> >
> > >> >I don't think including the functionality now (as it's relatively
> > >>simple)
> > >> >would preclude integration into 1688. At that point the
> implementation
> > >>of
> > >> >the check might change, but as it's a broker config, there shouldn't
> be
> > >> >concerns about backward compatibility.
> > >> >
> > >> >Hope that helps
> > >> >
> > >> >Thanks
> > >> >
> > >> >Jeff
> > >> >
> > >> >On Fri, Mar 20, 2015 at 12:26 PM, Jun Rao <ju...@confluent.io> wrote:
> > >> >
> > >> >> Yes, we can discuss the implementation separately.
> > >> >>
> > >> >> As for the proposal itself, have you looked at KAFKA-1688? Could
> this
> > >> >>just
> > >> >> be a special case for authorization and be included there?
> > >> >>
> > >> >> Thanks,
> > >> >>
> > >> >> Jun
> > >> >>
> > >> >> On Wed, Mar 18, 2015 at 6:26 PM, Jeff Holoman <
> jholoman@cloudera.com
> > >
> > >> >> wrote:
> > >> >>
> > >> >> > One other thought. Does the timing of the implementation (or lack
> > >> >> thereof)
> > >> >> > affect the proposal? It seems like the question you are asking is
> > >>an
> > >> >> > implementation detail in terms of when the work would be done. If
> > >> >>there
> > >> >> > isn't really support for the KIP that's ok, just wanting to make
> > >>sure
> > >> >>we
> > >> >> > are segmenting the vote for the KIP from concerns about
> > >>implementation
> > >> >> > timing.
> > >> >> >
> > >> >> > Thanks!
> > >> >> >
> > >> >> > Jeff
> > >> >> >
> > >> >> > On Wed, Mar 18, 2015 at 9:22 PM, Jeff Holoman
> > >><jh...@cloudera.com>
> > >> >> > wrote:
> > >> >> >
> > >> >> > > Hey Jun thanks for the comment.
> > >> >> > >
> > >> >> > > Is the plan to re-factor the SocketServer implementation
> > >> >>significantly?
> > >> >> > > The current check is just in the acceptor. Does this change
> with
> > >>the
> > >> >> > > refactor?
> > >> >> > >
> > >> >> > > Thanks
> > >> >> > >
> > >> >> > > Jeff
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > > On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <ju...@confluent.io>
> > >>wrote:
> > >> >> > >
> > >> >> > >> The proposal sounds reasonable. Timing wise, since we plan to
> > >> >>refactor
> > >> >> > the
> > >> >> > >> network layer code in the broker, perhaps this can wait until
> > >> >> KAFKA-1928
> > >> >> > >> is
> > >> >> > >> done?
> > >> >> > >>
> > >> >> > >> Thanks,
> > >> >> > >>
> > >> >> > >> Jun
> > >> >> > >>
> > >> >> > >> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman
> > >> >><jh...@cloudera.com>
> > >> >> > >> wrote:
> > >> >> > >>
> > >> >> > >> > bump
> > >> >> > >> >
> > >> >> > >> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman
> > >> >><jholoman@cloudera.com
> > >> >> >
> > >> >> > >> > wrote:
> > >> >> > >> >
> > >> >> > >> > > Guozhang,
> > >> >> > >> > >
> > >> >> > >> > > The way the patch is implemented, the check is done in the
> > >> >> acceptor
> > >> >> > >> > thread
> > >> >> > >> > > accept() method of the Socket Server, just before
> > >> >> connectionQuotas.
> > >> >> > >> > >
> > >> >> > >> > > Thanks
> > >> >> > >> > >
> > >> >> > >> > > Jeff
> > >> >> > >> > >
> > >> >> > >> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang
> > >> >><wangguoz@gmail.com
> > >> >> >
> > >> >> > >> > wrote:
> > >> >> > >> > >
> > >> >> > >> > >> Jeff,
> > >> >> > >> > >>
> > >> >> > >> > >> I am wondering if the IP filtering rule can be enforced
> at
> > >>the
> > >> >> > socket
> > >> >> > >> > >> server level instead of the Kafka API level?
> > >> >> > >> > >>
> > >> >> > >> > >> Guozhang
> > >> >> > >> > >>
> > >> >> > >> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin
> > >> >> > >> <jqin@linkedin.com.invalid
> > >> >> > >> > >
> > >> >> > >> > >> wrote:
> > >> >> > >> > >>
> > >> >> > >> > >> > +1 (non-binding)
> > >> >> > >> > >> >
> > >> >> > >> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira"
> > >><gs...@cloudera.com>
> > >> >> > wrote:
> > >> >> > >> > >> >
> > >> >> > >> > >> > >+1 (non-binding)
> > >> >> > >> > >> > >
> > >> >> > >> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <
> > >> >> > >> jholoman@cloudera.com
> > >> >> > >> > >
> > >> >> > >> > >> > >wrote:
> > >> >> > >> > >> > >> Details in the wiki.
> > >> >> > >> > >> > >>
> > >> >> > >> > >> > >>
> > >> >> > >> > >> > >>
> > >> >> > >> > >> > >>
> > >> >> > >> > >> >
> > >> >> > >> > >>
> > >> >> > >> >
> > >> >> > >>
> > >> >> >
> > >> >>
> > >> >>
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
> > >> >> > >> > >> > >>iltering
> > >> >> > >> > >> > >>
> > >> >> > >> > >> > >>
> > >> >> > >> > >> > >>
> > >> >> > >> > >> > >> --
> > >> >> > >> > >> > >> Jeff Holoman
> > >> >> > >> > >> > >> Systems Engineer
> > >> >> > >> > >> >
> > >> >> > >> > >> >
> > >> >> > >> > >>
> > >> >> > >> > >>
> > >> >> > >> > >> --
> > >> >> > >> > >> -- Guozhang
> > >> >> > >> > >>
> > >> >> > >> > >
> > >> >> > >> > >
> > >> >> > >> > >
> > >> >> > >> > > --
> > >> >> > >> > > Jeff Holoman
> > >> >> > >> > > Systems Engineer
> > >> >> > >> > >
> > >> >> > >> > >
> > >> >> > >> > >
> > >> >> > >> > >
> > >> >> > >> >
> > >> >> > >> >
> > >> >> > >> > --
> > >> >> > >> > Jeff Holoman
> > >> >> > >> > Systems Engineer
> > >> >> > >> >
> > >> >> > >>
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > > --
> > >> >> > > Jeff Holoman
> > >> >> > > Systems Engineer
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> >
> > >> >> >
> > >> >> > --
> > >> >> > Jeff Holoman
> > >> >> > Systems Engineer
> > >> >> >
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> >--
> > >> >Jeff Holoman
> > >> >Systems Engineer
> > >>
> > >>
> >
> >
>
>
> --
> Jeff Holoman
> Systems Engineer
>
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Jeff Holoman <jh...@cloudera.com>.
Parth,
I think it's important to understand the timing of both the initial JIRA
and the KIP, it helps put my comments in proper context.
The initial JIRA for this was created back in December, so the timeline for
1688/KIP-11 was pretty unclear. KIP-7 came out when we started doing KIPs,
back in Jan. The initial comments I think pretty clearly acknowledged the
work on 1688.
My comment re: integration was that perhaps the check logic could be reused
(i.e, the CIDR range checks). That's what I meant when I mentioned "the
intent". At that point there was no KIP-11 and no patch, so it was just a
hunch.
In terms of it being a different use case, I do think there are some
aspects which would be beneficial, even given the work on 1688.
1) Simplicity
2) Less config - 2 params
3) Allows for both whitelisting and blacklisting, giving a bit more
flexibility.
Another key driver, at least at the time, was timing. As this discussion
has been extended that becomes less of a motivator, which I understand.
I don't necessarily think that giving users options to limit access will
confuse them, given the new interface for security will likely take a bit
of understanding to implement correctly. In fact they might be quite
complimentary.
Lets take the 2nd example in KIP 11:
user2.hosts=*
user2.operation=read
So if I understand correctly, this would allow read access for a particular
topic from any host for a given user. it could be helpful to block a range
of IPs (like production or QA) but otherwise not specify every potential
host that needs to read from that topic.
As you mentioned adding additional constructs make the ACL's a bit more
complex, maybe this provides some relief there.
Jun, if folks feel like there's too much overlap, and this wouldn't be
useful, then that's fair. That's what the votes are for right? :)
Thanks
Jeff
On Fri, Mar 20, 2015 at 6:01 PM, Parth Brahmbhatt <
pbrahmbhatt@hortonworks.com> wrote:
> I am guessing in your last reply you meant KIP-11. And yes, I think KIP-11
> subsumed KIP-7 so if we can finish KIP-11 we should not need KIP=7 but I
> will let Jeff confirm that,
>
> Thanks
> Parth
>
>
> On 3/20/15, 2:32 PM, "Jun Rao" <ju...@confluent.io> wrote:
>
> >Right, if this KIP is subsumed by KIP-7, perhaps we just need to wait
> >until
> >KIP-7 is done? If we add the small change now, we will have to worry about
> >migrating existing users and deprecating some configs when KIP-7 is done.
> >
> >Thanks,
> >
> >Jun
> >
> >On Fri, Mar 20, 2015 at 10:36 AM, Parth Brahmbhatt <
> >pbrahmbhatt@hortonworks.com> wrote:
> >
> >> I am not entirely sure what you mean by integrating KIP-7 work with
> >> KAFKA-1688. Wouldn¹t the work done as part of KIP-7 become obsolete once
> >> KAFKA-1688 is done? Multiple ways of controlling these authorization
> >>just
> >> seems extra configuration that will confuse admins/users.
> >>
> >> If timing is the only issue don¹t you think its better to focus our
> >>energy
> >> on getting 1688 done faster which seem to be the longer term goal
> >>anyways?
> >>
> >> Thanks
> >> Parth
> >>
> >> On 3/20/15, 10:28 AM, "Jeff Holoman" <jh...@cloudera.com> wrote:
> >>
> >> >Hey Jun,
> >> >
> >> >The intent was for the same functionality to be utilized when 1688 is
> >> >done,
> >> >as mentioned in the KIP:
> >> >
> >> >"The broader security initiative <http://kafka-1682/> will add more
> >> robust
> >> >controls for these types of environments, and this proposal could be
> >> >integrated with that work at the appropriate time. This is also the
> >> >specific request of a large financial services company."
> >> >
> >> >I don't think including the functionality now (as it's relatively
> >>simple)
> >> >would preclude integration into 1688. At that point the implementation
> >>of
> >> >the check might change, but as it's a broker config, there shouldn't be
> >> >concerns about backward compatibility.
> >> >
> >> >Hope that helps
> >> >
> >> >Thanks
> >> >
> >> >Jeff
> >> >
> >> >On Fri, Mar 20, 2015 at 12:26 PM, Jun Rao <ju...@confluent.io> wrote:
> >> >
> >> >> Yes, we can discuss the implementation separately.
> >> >>
> >> >> As for the proposal itself, have you looked at KAFKA-1688? Could this
> >> >>just
> >> >> be a special case for authorization and be included there?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Jun
> >> >>
> >> >> On Wed, Mar 18, 2015 at 6:26 PM, Jeff Holoman <jholoman@cloudera.com
> >
> >> >> wrote:
> >> >>
> >> >> > One other thought. Does the timing of the implementation (or lack
> >> >> thereof)
> >> >> > affect the proposal? It seems like the question you are asking is
> >>an
> >> >> > implementation detail in terms of when the work would be done. If
> >> >>there
> >> >> > isn't really support for the KIP that's ok, just wanting to make
> >>sure
> >> >>we
> >> >> > are segmenting the vote for the KIP from concerns about
> >>implementation
> >> >> > timing.
> >> >> >
> >> >> > Thanks!
> >> >> >
> >> >> > Jeff
> >> >> >
> >> >> > On Wed, Mar 18, 2015 at 9:22 PM, Jeff Holoman
> >><jh...@cloudera.com>
> >> >> > wrote:
> >> >> >
> >> >> > > Hey Jun thanks for the comment.
> >> >> > >
> >> >> > > Is the plan to re-factor the SocketServer implementation
> >> >>significantly?
> >> >> > > The current check is just in the acceptor. Does this change with
> >>the
> >> >> > > refactor?
> >> >> > >
> >> >> > > Thanks
> >> >> > >
> >> >> > > Jeff
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <ju...@confluent.io>
> >>wrote:
> >> >> > >
> >> >> > >> The proposal sounds reasonable. Timing wise, since we plan to
> >> >>refactor
> >> >> > the
> >> >> > >> network layer code in the broker, perhaps this can wait until
> >> >> KAFKA-1928
> >> >> > >> is
> >> >> > >> done?
> >> >> > >>
> >> >> > >> Thanks,
> >> >> > >>
> >> >> > >> Jun
> >> >> > >>
> >> >> > >> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman
> >> >><jh...@cloudera.com>
> >> >> > >> wrote:
> >> >> > >>
> >> >> > >> > bump
> >> >> > >> >
> >> >> > >> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman
> >> >><jholoman@cloudera.com
> >> >> >
> >> >> > >> > wrote:
> >> >> > >> >
> >> >> > >> > > Guozhang,
> >> >> > >> > >
> >> >> > >> > > The way the patch is implemented, the check is done in the
> >> >> acceptor
> >> >> > >> > thread
> >> >> > >> > > accept() method of the Socket Server, just before
> >> >> connectionQuotas.
> >> >> > >> > >
> >> >> > >> > > Thanks
> >> >> > >> > >
> >> >> > >> > > Jeff
> >> >> > >> > >
> >> >> > >> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang
> >> >><wangguoz@gmail.com
> >> >> >
> >> >> > >> > wrote:
> >> >> > >> > >
> >> >> > >> > >> Jeff,
> >> >> > >> > >>
> >> >> > >> > >> I am wondering if the IP filtering rule can be enforced at
> >>the
> >> >> > socket
> >> >> > >> > >> server level instead of the Kafka API level?
> >> >> > >> > >>
> >> >> > >> > >> Guozhang
> >> >> > >> > >>
> >> >> > >> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin
> >> >> > >> <jqin@linkedin.com.invalid
> >> >> > >> > >
> >> >> > >> > >> wrote:
> >> >> > >> > >>
> >> >> > >> > >> > +1 (non-binding)
> >> >> > >> > >> >
> >> >> > >> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira"
> >><gs...@cloudera.com>
> >> >> > wrote:
> >> >> > >> > >> >
> >> >> > >> > >> > >+1 (non-binding)
> >> >> > >> > >> > >
> >> >> > >> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <
> >> >> > >> jholoman@cloudera.com
> >> >> > >> > >
> >> >> > >> > >> > >wrote:
> >> >> > >> > >> > >> Details in the wiki.
> >> >> > >> > >> > >>
> >> >> > >> > >> > >>
> >> >> > >> > >> > >>
> >> >> > >> > >> > >>
> >> >> > >> > >> >
> >> >> > >> > >>
> >> >> > >> >
> >> >> > >>
> >> >> >
> >> >>
> >> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
> >> >> > >> > >> > >>iltering
> >> >> > >> > >> > >>
> >> >> > >> > >> > >>
> >> >> > >> > >> > >>
> >> >> > >> > >> > >> --
> >> >> > >> > >> > >> Jeff Holoman
> >> >> > >> > >> > >> Systems Engineer
> >> >> > >> > >> >
> >> >> > >> > >> >
> >> >> > >> > >>
> >> >> > >> > >>
> >> >> > >> > >> --
> >> >> > >> > >> -- Guozhang
> >> >> > >> > >>
> >> >> > >> > >
> >> >> > >> > >
> >> >> > >> > >
> >> >> > >> > > --
> >> >> > >> > > Jeff Holoman
> >> >> > >> > > Systems Engineer
> >> >> > >> > >
> >> >> > >> > >
> >> >> > >> > >
> >> >> > >> > >
> >> >> > >> >
> >> >> > >> >
> >> >> > >> > --
> >> >> > >> > Jeff Holoman
> >> >> > >> > Systems Engineer
> >> >> > >> >
> >> >> > >>
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Jeff Holoman
> >> >> > > Systems Engineer
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Jeff Holoman
> >> >> > Systems Engineer
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> >--
> >> >Jeff Holoman
> >> >Systems Engineer
> >>
> >>
>
>
--
Jeff Holoman
Systems Engineer
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Parth Brahmbhatt <pb...@hortonworks.com>.
I am guessing in your last reply you meant KIP-11. And yes, I think KIP-11
subsumed KIP-7 so if we can finish KIP-11 we should not need KIP=7 but I
will let Jeff confirm that,
Thanks
Parth
On 3/20/15, 2:32 PM, "Jun Rao" <ju...@confluent.io> wrote:
>Right, if this KIP is subsumed by KIP-7, perhaps we just need to wait
>until
>KIP-7 is done? If we add the small change now, we will have to worry about
>migrating existing users and deprecating some configs when KIP-7 is done.
>
>Thanks,
>
>Jun
>
>On Fri, Mar 20, 2015 at 10:36 AM, Parth Brahmbhatt <
>pbrahmbhatt@hortonworks.com> wrote:
>
>> I am not entirely sure what you mean by integrating KIP-7 work with
>> KAFKA-1688. Wouldn¹t the work done as part of KIP-7 become obsolete once
>> KAFKA-1688 is done? Multiple ways of controlling these authorization
>>just
>> seems extra configuration that will confuse admins/users.
>>
>> If timing is the only issue don¹t you think its better to focus our
>>energy
>> on getting 1688 done faster which seem to be the longer term goal
>>anyways?
>>
>> Thanks
>> Parth
>>
>> On 3/20/15, 10:28 AM, "Jeff Holoman" <jh...@cloudera.com> wrote:
>>
>> >Hey Jun,
>> >
>> >The intent was for the same functionality to be utilized when 1688 is
>> >done,
>> >as mentioned in the KIP:
>> >
>> >"The broader security initiative <http://kafka-1682/> will add more
>> robust
>> >controls for these types of environments, and this proposal could be
>> >integrated with that work at the appropriate time. This is also the
>> >specific request of a large financial services company."
>> >
>> >I don't think including the functionality now (as it's relatively
>>simple)
>> >would preclude integration into 1688. At that point the implementation
>>of
>> >the check might change, but as it's a broker config, there shouldn't be
>> >concerns about backward compatibility.
>> >
>> >Hope that helps
>> >
>> >Thanks
>> >
>> >Jeff
>> >
>> >On Fri, Mar 20, 2015 at 12:26 PM, Jun Rao <ju...@confluent.io> wrote:
>> >
>> >> Yes, we can discuss the implementation separately.
>> >>
>> >> As for the proposal itself, have you looked at KAFKA-1688? Could this
>> >>just
>> >> be a special case for authorization and be included there?
>> >>
>> >> Thanks,
>> >>
>> >> Jun
>> >>
>> >> On Wed, Mar 18, 2015 at 6:26 PM, Jeff Holoman <jh...@cloudera.com>
>> >> wrote:
>> >>
>> >> > One other thought. Does the timing of the implementation (or lack
>> >> thereof)
>> >> > affect the proposal? It seems like the question you are asking is
>>an
>> >> > implementation detail in terms of when the work would be done. If
>> >>there
>> >> > isn't really support for the KIP that's ok, just wanting to make
>>sure
>> >>we
>> >> > are segmenting the vote for the KIP from concerns about
>>implementation
>> >> > timing.
>> >> >
>> >> > Thanks!
>> >> >
>> >> > Jeff
>> >> >
>> >> > On Wed, Mar 18, 2015 at 9:22 PM, Jeff Holoman
>><jh...@cloudera.com>
>> >> > wrote:
>> >> >
>> >> > > Hey Jun thanks for the comment.
>> >> > >
>> >> > > Is the plan to re-factor the SocketServer implementation
>> >>significantly?
>> >> > > The current check is just in the acceptor. Does this change with
>>the
>> >> > > refactor?
>> >> > >
>> >> > > Thanks
>> >> > >
>> >> > > Jeff
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <ju...@confluent.io>
>>wrote:
>> >> > >
>> >> > >> The proposal sounds reasonable. Timing wise, since we plan to
>> >>refactor
>> >> > the
>> >> > >> network layer code in the broker, perhaps this can wait until
>> >> KAFKA-1928
>> >> > >> is
>> >> > >> done?
>> >> > >>
>> >> > >> Thanks,
>> >> > >>
>> >> > >> Jun
>> >> > >>
>> >> > >> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman
>> >><jh...@cloudera.com>
>> >> > >> wrote:
>> >> > >>
>> >> > >> > bump
>> >> > >> >
>> >> > >> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman
>> >><jholoman@cloudera.com
>> >> >
>> >> > >> > wrote:
>> >> > >> >
>> >> > >> > > Guozhang,
>> >> > >> > >
>> >> > >> > > The way the patch is implemented, the check is done in the
>> >> acceptor
>> >> > >> > thread
>> >> > >> > > accept() method of the Socket Server, just before
>> >> connectionQuotas.
>> >> > >> > >
>> >> > >> > > Thanks
>> >> > >> > >
>> >> > >> > > Jeff
>> >> > >> > >
>> >> > >> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang
>> >><wangguoz@gmail.com
>> >> >
>> >> > >> > wrote:
>> >> > >> > >
>> >> > >> > >> Jeff,
>> >> > >> > >>
>> >> > >> > >> I am wondering if the IP filtering rule can be enforced at
>>the
>> >> > socket
>> >> > >> > >> server level instead of the Kafka API level?
>> >> > >> > >>
>> >> > >> > >> Guozhang
>> >> > >> > >>
>> >> > >> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin
>> >> > >> <jqin@linkedin.com.invalid
>> >> > >> > >
>> >> > >> > >> wrote:
>> >> > >> > >>
>> >> > >> > >> > +1 (non-binding)
>> >> > >> > >> >
>> >> > >> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira"
>><gs...@cloudera.com>
>> >> > wrote:
>> >> > >> > >> >
>> >> > >> > >> > >+1 (non-binding)
>> >> > >> > >> > >
>> >> > >> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <
>> >> > >> jholoman@cloudera.com
>> >> > >> > >
>> >> > >> > >> > >wrote:
>> >> > >> > >> > >> Details in the wiki.
>> >> > >> > >> > >>
>> >> > >> > >> > >>
>> >> > >> > >> > >>
>> >> > >> > >> > >>
>> >> > >> > >> >
>> >> > >> > >>
>> >> > >> >
>> >> > >>
>> >> >
>> >>
>> >>
>>
>>https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
>> >> > >> > >> > >>iltering
>> >> > >> > >> > >>
>> >> > >> > >> > >>
>> >> > >> > >> > >>
>> >> > >> > >> > >> --
>> >> > >> > >> > >> Jeff Holoman
>> >> > >> > >> > >> Systems Engineer
>> >> > >> > >> >
>> >> > >> > >> >
>> >> > >> > >>
>> >> > >> > >>
>> >> > >> > >> --
>> >> > >> > >> -- Guozhang
>> >> > >> > >>
>> >> > >> > >
>> >> > >> > >
>> >> > >> > >
>> >> > >> > > --
>> >> > >> > > Jeff Holoman
>> >> > >> > > Systems Engineer
>> >> > >> > >
>> >> > >> > >
>> >> > >> > >
>> >> > >> > >
>> >> > >> >
>> >> > >> >
>> >> > >> > --
>> >> > >> > Jeff Holoman
>> >> > >> > Systems Engineer
>> >> > >> >
>> >> > >>
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Jeff Holoman
>> >> > > Systems Engineer
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > Jeff Holoman
>> >> > Systems Engineer
>> >> >
>> >>
>> >
>> >
>> >
>> >--
>> >Jeff Holoman
>> >Systems Engineer
>>
>>
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Jun Rao <ju...@confluent.io>.
Right, if this KIP is subsumed by KIP-7, perhaps we just need to wait until
KIP-7 is done? If we add the small change now, we will have to worry about
migrating existing users and deprecating some configs when KIP-7 is done.
Thanks,
Jun
On Fri, Mar 20, 2015 at 10:36 AM, Parth Brahmbhatt <
pbrahmbhatt@hortonworks.com> wrote:
> I am not entirely sure what you mean by integrating KIP-7 work with
> KAFKA-1688. Wouldn¹t the work done as part of KIP-7 become obsolete once
> KAFKA-1688 is done? Multiple ways of controlling these authorization just
> seems extra configuration that will confuse admins/users.
>
> If timing is the only issue don¹t you think its better to focus our energy
> on getting 1688 done faster which seem to be the longer term goal anyways?
>
> Thanks
> Parth
>
> On 3/20/15, 10:28 AM, "Jeff Holoman" <jh...@cloudera.com> wrote:
>
> >Hey Jun,
> >
> >The intent was for the same functionality to be utilized when 1688 is
> >done,
> >as mentioned in the KIP:
> >
> >"The broader security initiative <http://kafka-1682/> will add more
> robust
> >controls for these types of environments, and this proposal could be
> >integrated with that work at the appropriate time. This is also the
> >specific request of a large financial services company."
> >
> >I don't think including the functionality now (as it's relatively simple)
> >would preclude integration into 1688. At that point the implementation of
> >the check might change, but as it's a broker config, there shouldn't be
> >concerns about backward compatibility.
> >
> >Hope that helps
> >
> >Thanks
> >
> >Jeff
> >
> >On Fri, Mar 20, 2015 at 12:26 PM, Jun Rao <ju...@confluent.io> wrote:
> >
> >> Yes, we can discuss the implementation separately.
> >>
> >> As for the proposal itself, have you looked at KAFKA-1688? Could this
> >>just
> >> be a special case for authorization and be included there?
> >>
> >> Thanks,
> >>
> >> Jun
> >>
> >> On Wed, Mar 18, 2015 at 6:26 PM, Jeff Holoman <jh...@cloudera.com>
> >> wrote:
> >>
> >> > One other thought. Does the timing of the implementation (or lack
> >> thereof)
> >> > affect the proposal? It seems like the question you are asking is an
> >> > implementation detail in terms of when the work would be done. If
> >>there
> >> > isn't really support for the KIP that's ok, just wanting to make sure
> >>we
> >> > are segmenting the vote for the KIP from concerns about implementation
> >> > timing.
> >> >
> >> > Thanks!
> >> >
> >> > Jeff
> >> >
> >> > On Wed, Mar 18, 2015 at 9:22 PM, Jeff Holoman <jh...@cloudera.com>
> >> > wrote:
> >> >
> >> > > Hey Jun thanks for the comment.
> >> > >
> >> > > Is the plan to re-factor the SocketServer implementation
> >>significantly?
> >> > > The current check is just in the acceptor. Does this change with the
> >> > > refactor?
> >> > >
> >> > > Thanks
> >> > >
> >> > > Jeff
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <ju...@confluent.io> wrote:
> >> > >
> >> > >> The proposal sounds reasonable. Timing wise, since we plan to
> >>refactor
> >> > the
> >> > >> network layer code in the broker, perhaps this can wait until
> >> KAFKA-1928
> >> > >> is
> >> > >> done?
> >> > >>
> >> > >> Thanks,
> >> > >>
> >> > >> Jun
> >> > >>
> >> > >> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman
> >><jh...@cloudera.com>
> >> > >> wrote:
> >> > >>
> >> > >> > bump
> >> > >> >
> >> > >> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman
> >><jholoman@cloudera.com
> >> >
> >> > >> > wrote:
> >> > >> >
> >> > >> > > Guozhang,
> >> > >> > >
> >> > >> > > The way the patch is implemented, the check is done in the
> >> acceptor
> >> > >> > thread
> >> > >> > > accept() method of the Socket Server, just before
> >> connectionQuotas.
> >> > >> > >
> >> > >> > > Thanks
> >> > >> > >
> >> > >> > > Jeff
> >> > >> > >
> >> > >> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang
> >><wangguoz@gmail.com
> >> >
> >> > >> > wrote:
> >> > >> > >
> >> > >> > >> Jeff,
> >> > >> > >>
> >> > >> > >> I am wondering if the IP filtering rule can be enforced at the
> >> > socket
> >> > >> > >> server level instead of the Kafka API level?
> >> > >> > >>
> >> > >> > >> Guozhang
> >> > >> > >>
> >> > >> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin
> >> > >> <jqin@linkedin.com.invalid
> >> > >> > >
> >> > >> > >> wrote:
> >> > >> > >>
> >> > >> > >> > +1 (non-binding)
> >> > >> > >> >
> >> > >> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com>
> >> > wrote:
> >> > >> > >> >
> >> > >> > >> > >+1 (non-binding)
> >> > >> > >> > >
> >> > >> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <
> >> > >> jholoman@cloudera.com
> >> > >> > >
> >> > >> > >> > >wrote:
> >> > >> > >> > >> Details in the wiki.
> >> > >> > >> > >>
> >> > >> > >> > >>
> >> > >> > >> > >>
> >> > >> > >> > >>
> >> > >> > >> >
> >> > >> > >>
> >> > >> >
> >> > >>
> >> >
> >>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
> >> > >> > >> > >>iltering
> >> > >> > >> > >>
> >> > >> > >> > >>
> >> > >> > >> > >>
> >> > >> > >> > >> --
> >> > >> > >> > >> Jeff Holoman
> >> > >> > >> > >> Systems Engineer
> >> > >> > >> >
> >> > >> > >> >
> >> > >> > >>
> >> > >> > >>
> >> > >> > >> --
> >> > >> > >> -- Guozhang
> >> > >> > >>
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > > --
> >> > >> > > Jeff Holoman
> >> > >> > > Systems Engineer
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> >
> >> > >> >
> >> > >> > --
> >> > >> > Jeff Holoman
> >> > >> > Systems Engineer
> >> > >> >
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Jeff Holoman
> >> > > Systems Engineer
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Jeff Holoman
> >> > Systems Engineer
> >> >
> >>
> >
> >
> >
> >--
> >Jeff Holoman
> >Systems Engineer
>
>
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Parth Brahmbhatt <pb...@hortonworks.com>.
I am not entirely sure what you mean by integrating KIP-7 work with
KAFKA-1688. Wouldn¹t the work done as part of KIP-7 become obsolete once
KAFKA-1688 is done? Multiple ways of controlling these authorization just
seems extra configuration that will confuse admins/users.
If timing is the only issue don¹t you think its better to focus our energy
on getting 1688 done faster which seem to be the longer term goal anyways?
Thanks
Parth
On 3/20/15, 10:28 AM, "Jeff Holoman" <jh...@cloudera.com> wrote:
>Hey Jun,
>
>The intent was for the same functionality to be utilized when 1688 is
>done,
>as mentioned in the KIP:
>
>"The broader security initiative <http://kafka-1682/> will add more robust
>controls for these types of environments, and this proposal could be
>integrated with that work at the appropriate time. This is also the
>specific request of a large financial services company."
>
>I don't think including the functionality now (as it's relatively simple)
>would preclude integration into 1688. At that point the implementation of
>the check might change, but as it's a broker config, there shouldn't be
>concerns about backward compatibility.
>
>Hope that helps
>
>Thanks
>
>Jeff
>
>On Fri, Mar 20, 2015 at 12:26 PM, Jun Rao <ju...@confluent.io> wrote:
>
>> Yes, we can discuss the implementation separately.
>>
>> As for the proposal itself, have you looked at KAFKA-1688? Could this
>>just
>> be a special case for authorization and be included there?
>>
>> Thanks,
>>
>> Jun
>>
>> On Wed, Mar 18, 2015 at 6:26 PM, Jeff Holoman <jh...@cloudera.com>
>> wrote:
>>
>> > One other thought. Does the timing of the implementation (or lack
>> thereof)
>> > affect the proposal? It seems like the question you are asking is an
>> > implementation detail in terms of when the work would be done. If
>>there
>> > isn't really support for the KIP that's ok, just wanting to make sure
>>we
>> > are segmenting the vote for the KIP from concerns about implementation
>> > timing.
>> >
>> > Thanks!
>> >
>> > Jeff
>> >
>> > On Wed, Mar 18, 2015 at 9:22 PM, Jeff Holoman <jh...@cloudera.com>
>> > wrote:
>> >
>> > > Hey Jun thanks for the comment.
>> > >
>> > > Is the plan to re-factor the SocketServer implementation
>>significantly?
>> > > The current check is just in the acceptor. Does this change with the
>> > > refactor?
>> > >
>> > > Thanks
>> > >
>> > > Jeff
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <ju...@confluent.io> wrote:
>> > >
>> > >> The proposal sounds reasonable. Timing wise, since we plan to
>>refactor
>> > the
>> > >> network layer code in the broker, perhaps this can wait until
>> KAFKA-1928
>> > >> is
>> > >> done?
>> > >>
>> > >> Thanks,
>> > >>
>> > >> Jun
>> > >>
>> > >> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman
>><jh...@cloudera.com>
>> > >> wrote:
>> > >>
>> > >> > bump
>> > >> >
>> > >> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman
>><jholoman@cloudera.com
>> >
>> > >> > wrote:
>> > >> >
>> > >> > > Guozhang,
>> > >> > >
>> > >> > > The way the patch is implemented, the check is done in the
>> acceptor
>> > >> > thread
>> > >> > > accept() method of the Socket Server, just before
>> connectionQuotas.
>> > >> > >
>> > >> > > Thanks
>> > >> > >
>> > >> > > Jeff
>> > >> > >
>> > >> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang
>><wangguoz@gmail.com
>> >
>> > >> > wrote:
>> > >> > >
>> > >> > >> Jeff,
>> > >> > >>
>> > >> > >> I am wondering if the IP filtering rule can be enforced at the
>> > socket
>> > >> > >> server level instead of the Kafka API level?
>> > >> > >>
>> > >> > >> Guozhang
>> > >> > >>
>> > >> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin
>> > >> <jqin@linkedin.com.invalid
>> > >> > >
>> > >> > >> wrote:
>> > >> > >>
>> > >> > >> > +1 (non-binding)
>> > >> > >> >
>> > >> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com>
>> > wrote:
>> > >> > >> >
>> > >> > >> > >+1 (non-binding)
>> > >> > >> > >
>> > >> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <
>> > >> jholoman@cloudera.com
>> > >> > >
>> > >> > >> > >wrote:
>> > >> > >> > >> Details in the wiki.
>> > >> > >> > >>
>> > >> > >> > >>
>> > >> > >> > >>
>> > >> > >> > >>
>> > >> > >> >
>> > >> > >>
>> > >> >
>> > >>
>> >
>>
>>https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
>> > >> > >> > >>iltering
>> > >> > >> > >>
>> > >> > >> > >>
>> > >> > >> > >>
>> > >> > >> > >> --
>> > >> > >> > >> Jeff Holoman
>> > >> > >> > >> Systems Engineer
>> > >> > >> >
>> > >> > >> >
>> > >> > >>
>> > >> > >>
>> > >> > >> --
>> > >> > >> -- Guozhang
>> > >> > >>
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > --
>> > >> > > Jeff Holoman
>> > >> > > Systems Engineer
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Jeff Holoman
>> > >> > Systems Engineer
>> > >> >
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Jeff Holoman
>> > > Systems Engineer
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Jeff Holoman
>> > Systems Engineer
>> >
>>
>
>
>
>--
>Jeff Holoman
>Systems Engineer
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Jeff Holoman <jh...@cloudera.com>.
Hey Jun,
The intent was for the same functionality to be utilized when 1688 is done,
as mentioned in the KIP:
"The broader security initiative <http://kafka-1682/> will add more robust
controls for these types of environments, and this proposal could be
integrated with that work at the appropriate time. This is also the
specific request of a large financial services company."
I don't think including the functionality now (as it's relatively simple)
would preclude integration into 1688. At that point the implementation of
the check might change, but as it's a broker config, there shouldn't be
concerns about backward compatibility.
Hope that helps
Thanks
Jeff
On Fri, Mar 20, 2015 at 12:26 PM, Jun Rao <ju...@confluent.io> wrote:
> Yes, we can discuss the implementation separately.
>
> As for the proposal itself, have you looked at KAFKA-1688? Could this just
> be a special case for authorization and be included there?
>
> Thanks,
>
> Jun
>
> On Wed, Mar 18, 2015 at 6:26 PM, Jeff Holoman <jh...@cloudera.com>
> wrote:
>
> > One other thought. Does the timing of the implementation (or lack
> thereof)
> > affect the proposal? It seems like the question you are asking is an
> > implementation detail in terms of when the work would be done. If there
> > isn't really support for the KIP that's ok, just wanting to make sure we
> > are segmenting the vote for the KIP from concerns about implementation
> > timing.
> >
> > Thanks!
> >
> > Jeff
> >
> > On Wed, Mar 18, 2015 at 9:22 PM, Jeff Holoman <jh...@cloudera.com>
> > wrote:
> >
> > > Hey Jun thanks for the comment.
> > >
> > > Is the plan to re-factor the SocketServer implementation significantly?
> > > The current check is just in the acceptor. Does this change with the
> > > refactor?
> > >
> > > Thanks
> > >
> > > Jeff
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <ju...@confluent.io> wrote:
> > >
> > >> The proposal sounds reasonable. Timing wise, since we plan to refactor
> > the
> > >> network layer code in the broker, perhaps this can wait until
> KAFKA-1928
> > >> is
> > >> done?
> > >>
> > >> Thanks,
> > >>
> > >> Jun
> > >>
> > >> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman <jh...@cloudera.com>
> > >> wrote:
> > >>
> > >> > bump
> > >> >
> > >> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman <jholoman@cloudera.com
> >
> > >> > wrote:
> > >> >
> > >> > > Guozhang,
> > >> > >
> > >> > > The way the patch is implemented, the check is done in the
> acceptor
> > >> > thread
> > >> > > accept() method of the Socket Server, just before
> connectionQuotas.
> > >> > >
> > >> > > Thanks
> > >> > >
> > >> > > Jeff
> > >> > >
> > >> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang <wangguoz@gmail.com
> >
> > >> > wrote:
> > >> > >
> > >> > >> Jeff,
> > >> > >>
> > >> > >> I am wondering if the IP filtering rule can be enforced at the
> > socket
> > >> > >> server level instead of the Kafka API level?
> > >> > >>
> > >> > >> Guozhang
> > >> > >>
> > >> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin
> > >> <jqin@linkedin.com.invalid
> > >> > >
> > >> > >> wrote:
> > >> > >>
> > >> > >> > +1 (non-binding)
> > >> > >> >
> > >> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com>
> > wrote:
> > >> > >> >
> > >> > >> > >+1 (non-binding)
> > >> > >> > >
> > >> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <
> > >> jholoman@cloudera.com
> > >> > >
> > >> > >> > >wrote:
> > >> > >> > >> Details in the wiki.
> > >> > >> > >>
> > >> > >> > >>
> > >> > >> > >>
> > >> > >> > >>
> > >> > >> >
> > >> > >>
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
> > >> > >> > >>iltering
> > >> > >> > >>
> > >> > >> > >>
> > >> > >> > >>
> > >> > >> > >> --
> > >> > >> > >> Jeff Holoman
> > >> > >> > >> Systems Engineer
> > >> > >> >
> > >> > >> >
> > >> > >>
> > >> > >>
> > >> > >> --
> > >> > >> -- Guozhang
> > >> > >>
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Jeff Holoman
> > >> > > Systems Engineer
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Jeff Holoman
> > >> > Systems Engineer
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Jeff Holoman
> > > Systems Engineer
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Jeff Holoman
> > Systems Engineer
> >
>
--
Jeff Holoman
Systems Engineer
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Jun Rao <ju...@confluent.io>.
Yes, we can discuss the implementation separately.
As for the proposal itself, have you looked at KAFKA-1688? Could this just
be a special case for authorization and be included there?
Thanks,
Jun
On Wed, Mar 18, 2015 at 6:26 PM, Jeff Holoman <jh...@cloudera.com> wrote:
> One other thought. Does the timing of the implementation (or lack thereof)
> affect the proposal? It seems like the question you are asking is an
> implementation detail in terms of when the work would be done. If there
> isn't really support for the KIP that's ok, just wanting to make sure we
> are segmenting the vote for the KIP from concerns about implementation
> timing.
>
> Thanks!
>
> Jeff
>
> On Wed, Mar 18, 2015 at 9:22 PM, Jeff Holoman <jh...@cloudera.com>
> wrote:
>
> > Hey Jun thanks for the comment.
> >
> > Is the plan to re-factor the SocketServer implementation significantly?
> > The current check is just in the acceptor. Does this change with the
> > refactor?
> >
> > Thanks
> >
> > Jeff
> >
> >
> >
> >
> >
> > On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <ju...@confluent.io> wrote:
> >
> >> The proposal sounds reasonable. Timing wise, since we plan to refactor
> the
> >> network layer code in the broker, perhaps this can wait until KAFKA-1928
> >> is
> >> done?
> >>
> >> Thanks,
> >>
> >> Jun
> >>
> >> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman <jh...@cloudera.com>
> >> wrote:
> >>
> >> > bump
> >> >
> >> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman <jh...@cloudera.com>
> >> > wrote:
> >> >
> >> > > Guozhang,
> >> > >
> >> > > The way the patch is implemented, the check is done in the acceptor
> >> > thread
> >> > > accept() method of the Socket Server, just before connectionQuotas.
> >> > >
> >> > > Thanks
> >> > >
> >> > > Jeff
> >> > >
> >> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang <wa...@gmail.com>
> >> > wrote:
> >> > >
> >> > >> Jeff,
> >> > >>
> >> > >> I am wondering if the IP filtering rule can be enforced at the
> socket
> >> > >> server level instead of the Kafka API level?
> >> > >>
> >> > >> Guozhang
> >> > >>
> >> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin
> >> <jqin@linkedin.com.invalid
> >> > >
> >> > >> wrote:
> >> > >>
> >> > >> > +1 (non-binding)
> >> > >> >
> >> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com>
> wrote:
> >> > >> >
> >> > >> > >+1 (non-binding)
> >> > >> > >
> >> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <
> >> jholoman@cloudera.com
> >> > >
> >> > >> > >wrote:
> >> > >> > >> Details in the wiki.
> >> > >> > >>
> >> > >> > >>
> >> > >> > >>
> >> > >> > >>
> >> > >> >
> >> > >>
> >> >
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
> >> > >> > >>iltering
> >> > >> > >>
> >> > >> > >>
> >> > >> > >>
> >> > >> > >> --
> >> > >> > >> Jeff Holoman
> >> > >> > >> Systems Engineer
> >> > >> >
> >> > >> >
> >> > >>
> >> > >>
> >> > >> --
> >> > >> -- Guozhang
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Jeff Holoman
> >> > > Systems Engineer
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Jeff Holoman
> >> > Systems Engineer
> >> >
> >>
> >
> >
> >
> > --
> > Jeff Holoman
> > Systems Engineer
> >
> >
> >
> >
>
>
> --
> Jeff Holoman
> Systems Engineer
>
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Jeff Holoman <jh...@cloudera.com>.
One other thought. Does the timing of the implementation (or lack thereof)
affect the proposal? It seems like the question you are asking is an
implementation detail in terms of when the work would be done. If there
isn't really support for the KIP that's ok, just wanting to make sure we
are segmenting the vote for the KIP from concerns about implementation
timing.
Thanks!
Jeff
On Wed, Mar 18, 2015 at 9:22 PM, Jeff Holoman <jh...@cloudera.com> wrote:
> Hey Jun thanks for the comment.
>
> Is the plan to re-factor the SocketServer implementation significantly?
> The current check is just in the acceptor. Does this change with the
> refactor?
>
> Thanks
>
> Jeff
>
>
>
>
>
> On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <ju...@confluent.io> wrote:
>
>> The proposal sounds reasonable. Timing wise, since we plan to refactor the
>> network layer code in the broker, perhaps this can wait until KAFKA-1928
>> is
>> done?
>>
>> Thanks,
>>
>> Jun
>>
>> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman <jh...@cloudera.com>
>> wrote:
>>
>> > bump
>> >
>> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman <jh...@cloudera.com>
>> > wrote:
>> >
>> > > Guozhang,
>> > >
>> > > The way the patch is implemented, the check is done in the acceptor
>> > thread
>> > > accept() method of the Socket Server, just before connectionQuotas.
>> > >
>> > > Thanks
>> > >
>> > > Jeff
>> > >
>> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang <wa...@gmail.com>
>> > wrote:
>> > >
>> > >> Jeff,
>> > >>
>> > >> I am wondering if the IP filtering rule can be enforced at the socket
>> > >> server level instead of the Kafka API level?
>> > >>
>> > >> Guozhang
>> > >>
>> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin
>> <jqin@linkedin.com.invalid
>> > >
>> > >> wrote:
>> > >>
>> > >> > +1 (non-binding)
>> > >> >
>> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com> wrote:
>> > >> >
>> > >> > >+1 (non-binding)
>> > >> > >
>> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <
>> jholoman@cloudera.com
>> > >
>> > >> > >wrote:
>> > >> > >> Details in the wiki.
>> > >> > >>
>> > >> > >>
>> > >> > >>
>> > >> > >>
>> > >> >
>> > >>
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
>> > >> > >>iltering
>> > >> > >>
>> > >> > >>
>> > >> > >>
>> > >> > >> --
>> > >> > >> Jeff Holoman
>> > >> > >> Systems Engineer
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >> --
>> > >> -- Guozhang
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Jeff Holoman
>> > > Systems Engineer
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Jeff Holoman
>> > Systems Engineer
>> >
>>
>
>
>
> --
> Jeff Holoman
> Systems Engineer
>
>
>
>
--
Jeff Holoman
Systems Engineer
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Jeff Holoman <jh...@cloudera.com>.
Hey Jun thanks for the comment.
Is the plan to re-factor the SocketServer implementation significantly? The
current check is just in the acceptor. Does this change with the refactor?
Thanks
Jeff
On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <ju...@confluent.io> wrote:
> The proposal sounds reasonable. Timing wise, since we plan to refactor the
> network layer code in the broker, perhaps this can wait until KAFKA-1928 is
> done?
>
> Thanks,
>
> Jun
>
> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman <jh...@cloudera.com>
> wrote:
>
> > bump
> >
> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman <jh...@cloudera.com>
> > wrote:
> >
> > > Guozhang,
> > >
> > > The way the patch is implemented, the check is done in the acceptor
> > thread
> > > accept() method of the Socket Server, just before connectionQuotas.
> > >
> > > Thanks
> > >
> > > Jeff
> > >
> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang <wa...@gmail.com>
> > wrote:
> > >
> > >> Jeff,
> > >>
> > >> I am wondering if the IP filtering rule can be enforced at the socket
> > >> server level instead of the Kafka API level?
> > >>
> > >> Guozhang
> > >>
> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin
> <jqin@linkedin.com.invalid
> > >
> > >> wrote:
> > >>
> > >> > +1 (non-binding)
> > >> >
> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com> wrote:
> > >> >
> > >> > >+1 (non-binding)
> > >> > >
> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <
> jholoman@cloudera.com
> > >
> > >> > >wrote:
> > >> > >> Details in the wiki.
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >>
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
> > >> > >>iltering
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> --
> > >> > >> Jeff Holoman
> > >> > >> Systems Engineer
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> -- Guozhang
> > >>
> > >
> > >
> > >
> > > --
> > > Jeff Holoman
> > > Systems Engineer
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Jeff Holoman
> > Systems Engineer
> >
>
--
Jeff Holoman
Systems Engineer
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Jun Rao <ju...@confluent.io>.
The proposal sounds reasonable. Timing wise, since we plan to refactor the
network layer code in the broker, perhaps this can wait until KAFKA-1928 is
done?
Thanks,
Jun
On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman <jh...@cloudera.com> wrote:
> bump
>
> On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman <jh...@cloudera.com>
> wrote:
>
> > Guozhang,
> >
> > The way the patch is implemented, the check is done in the acceptor
> thread
> > accept() method of the Socket Server, just before connectionQuotas.
> >
> > Thanks
> >
> > Jeff
> >
> > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang <wa...@gmail.com>
> wrote:
> >
> >> Jeff,
> >>
> >> I am wondering if the IP filtering rule can be enforced at the socket
> >> server level instead of the Kafka API level?
> >>
> >> Guozhang
> >>
> >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin <jqin@linkedin.com.invalid
> >
> >> wrote:
> >>
> >> > +1 (non-binding)
> >> >
> >> > On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com> wrote:
> >> >
> >> > >+1 (non-binding)
> >> > >
> >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <jholoman@cloudera.com
> >
> >> > >wrote:
> >> > >> Details in the wiki.
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> >
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
> >> > >>iltering
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Jeff Holoman
> >> > >> Systems Engineer
> >> >
> >> >
> >>
> >>
> >> --
> >> -- Guozhang
> >>
> >
> >
> >
> > --
> > Jeff Holoman
> > Systems Engineer
> >
> >
> >
> >
>
>
> --
> Jeff Holoman
> Systems Engineer
>
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Jeff Holoman <jh...@cloudera.com>.
bump
On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman <jh...@cloudera.com> wrote:
> Guozhang,
>
> The way the patch is implemented, the check is done in the acceptor thread
> accept() method of the Socket Server, just before connectionQuotas.
>
> Thanks
>
> Jeff
>
> On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang <wa...@gmail.com> wrote:
>
>> Jeff,
>>
>> I am wondering if the IP filtering rule can be enforced at the socket
>> server level instead of the Kafka API level?
>>
>> Guozhang
>>
>> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin <jq...@linkedin.com.invalid>
>> wrote:
>>
>> > +1 (non-binding)
>> >
>> > On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com> wrote:
>> >
>> > >+1 (non-binding)
>> > >
>> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <jh...@cloudera.com>
>> > >wrote:
>> > >> Details in the wiki.
>> > >>
>> > >>
>> > >>
>> > >>
>> >
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
>> > >>iltering
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Jeff Holoman
>> > >> Systems Engineer
>> >
>> >
>>
>>
>> --
>> -- Guozhang
>>
>
>
>
> --
> Jeff Holoman
> Systems Engineer
>
>
>
>
--
Jeff Holoman
Systems Engineer
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Jeff Holoman <jh...@cloudera.com>.
Guozhang,
The way the patch is implemented, the check is done in the acceptor thread
accept() method of the Socket Server, just before connectionQuotas.
Thanks
Jeff
On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang <wa...@gmail.com> wrote:
> Jeff,
>
> I am wondering if the IP filtering rule can be enforced at the socket
> server level instead of the Kafka API level?
>
> Guozhang
>
> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin <jq...@linkedin.com.invalid>
> wrote:
>
> > +1 (non-binding)
> >
> > On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com> wrote:
> >
> > >+1 (non-binding)
> > >
> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <jh...@cloudera.com>
> > >wrote:
> > >> Details in the wiki.
> > >>
> > >>
> > >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
> > >>iltering
> > >>
> > >>
> > >>
> > >> --
> > >> Jeff Holoman
> > >> Systems Engineer
> >
> >
>
>
> --
> -- Guozhang
>
--
Jeff Holoman
Systems Engineer
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Guozhang Wang <wa...@gmail.com>.
Jeff,
I am wondering if the IP filtering rule can be enforced at the socket
server level instead of the Kafka API level?
Guozhang
On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin <jq...@linkedin.com.invalid>
wrote:
> +1 (non-binding)
>
> On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com> wrote:
>
> >+1 (non-binding)
> >
> >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <jh...@cloudera.com>
> >wrote:
> >> Details in the wiki.
> >>
> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
> >>iltering
> >>
> >>
> >>
> >> --
> >> Jeff Holoman
> >> Systems Engineer
>
>
--
-- Guozhang
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Jiangjie Qin <jq...@linkedin.com.INVALID>.
+1 (non-binding)
On 3/3/15, 1:17 PM, "Gwen Shapira" <gs...@cloudera.com> wrote:
>+1 (non-binding)
>
>On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <jh...@cloudera.com>
>wrote:
>> Details in the wiki.
>>
>>
>>
>>https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F
>>iltering
>>
>>
>>
>> --
>> Jeff Holoman
>> Systems Engineer
Re: [VOTE] KIP-7 Security - IP Filtering
Posted by Gwen Shapira <gs...@cloudera.com>.
+1 (non-binding)
On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman <jh...@cloudera.com> wrote:
> Details in the wiki.
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+Filtering
>
>
>
> --
> Jeff Holoman
> Systems Engineer