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 < pbrahmbh...@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" <j...@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 < > >pbrahmbh...@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" <jholo...@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 <j...@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 <jholo...@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 > >><jholo...@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 <j...@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 > >> >><jholo...@cloudera.com> > >> >> > >> wrote: > >> >> > >> > >> >> > >> > bump > >> >> > >> > > >> >> > >> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman > >> >><jholo...@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 > >> >><wangg...@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 > >> >> > >> <j...@linkedin.com.invalid > >> >> > >> > > > >> >> > >> > >> wrote: > >> >> > >> > >> > >> >> > >> > >> > +1 (non-binding) > >> >> > >> > >> > > >> >> > >> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira" > >><gshap...@cloudera.com> > >> >> > wrote: > >> >> > >> > >> > > >> >> > >> > >> > >+1 (non-binding) > >> >> > >> > >> > > > >> >> > >> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman < > >> >> > >> jholo...@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
