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