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 <jholo...@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 < > 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 >
