+1 (non-binding)

-- 
Harsha


On April 24, 2015 at 9:59:09 AM, Parth Brahmbhatt (pbrahmbh...@hortonworks.com) 
wrote:

You are right, moved it to the default implementation section.  

Thanks  
Parth  

On 4/24/15, 9:52 AM, "Gwen Shapira" <gshap...@cloudera.com> wrote:  

>Sample ACL JSON and Zookeeper is in public API, but I thought it is  
>part of DefaultAuthorizer (Since Sentry and Argus won't be using  
>Zookeeper).  
>Am I wrong? Or is it the KIP?  
>  
>On Fri, Apr 24, 2015 at 9:49 AM, Parth Brahmbhatt  
><pbrahmbh...@hortonworks.com> wrote:  
>> Thanks for clarifying Gwen, KIP updated.  
>>  
>> I tried to make the distinction by creating a section for all public  
>>APIs  
>>  
>>https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+  
>>In  
>> terface#KIP-11-AuthorizationInterface-PublicInterfacesandclasses  
>>  
>> Let me know if you think there is a better way to reflect this.  
>>  
>> Thanks  
>> Parth  
>>  
>> On 4/24/15, 9:37 AM, "Gwen Shapira" <gshap...@cloudera.com> wrote:  
>>  
>>>+1 (non-binding)  
>>>  
>>>Two nitpicks for the wiki:  
>>>* Heartbeat is probably a READ and not CLUSTER operation. I'm pretty  
>>>sure new consumers need it to be part of a consumer group.  
>>>* Can you clearly separate which parts are the API (common to every  
>>>Authorizer) and which parts are DefaultAuthorizer implementation? It  
>>>will make reviews and Authorizer implementations a bit easier to know  
>>>exactly which is which.  
>>>  
>>>Gwen  
>>>  
>>>On Fri, Apr 24, 2015 at 9:28 AM, Parth Brahmbhatt  
>>><pbrahmbh...@hortonworks.com> wrote:  
>>>> Hi,  
>>>>  
>>>> I would like to open KIP-11 for voting.  
>>>>  
>>>> Thanks  
>>>> Parth  
>>>>  
>>>> On 4/22/15, 1:56 PM, "Parth Brahmbhatt" <pbrahmbh...@hortonworks.com>  
>>>> wrote:  
>>>>  
>>>>>Hi Jeff,  
>>>>>  
>>>>>Thanks a lot for the review. I think you have a valid point about acls  
>>>>>being duplicated and the simplest solution would be to modify acls  
>>>>>class  
>>>>>so they hold a set of principals instead of single principal. i.e  
>>>>>  
>>>>><user_a,user_b> has <READ,WRITE,DESCRIBE> Permissions on <Topic1> from  
>>>>><Host1, Host2, Host3>.  
>>>>>  
>>>>>I think the evaluation order only matters for the permissionType which  
>>>>>is  
>>>>>Deny acls should be evaluated before allow acls. To give you an  
>>>>>example  
>>>>>suppose we have following acls  
>>>>>  
>>>>>acl1 -> user1 is allowed to READ from all hosts.  
>>>>>acl2 -> host1 is allowed to READ regardless of who is the user.  
>>>>>acl3 -> host2 is allowed to READ regardless of who is the user.  
>>>>>  
>>>>>acl4 -> user1 is denied to READ from host1.  
>>>>>  
>>>>>As stated in the KIP we first evaluate DENY so if user1 tries to  
>>>>>access  
>>>>>from host1 he will be denied(acl4), even though both user1 and host1  
>>>>>has  
>>>>>acl’s for allow with wildcards (acl1, acl2).  
>>>>>If user1 tried to READ from host2 , the action will be allowed and it  
>>>>>does  
>>>>>not matter if we match acl3 or acl1 so I don’t think the evaluation  
>>>>>order  
>>>>>matters here.  
>>>>>  
>>>>>“Will people actually use hosts with users?” I really don’t know but  
>>>>>given  
>>>>>ACl’s are part of our Public APIs I thought it is better to try and  
>>>>>cover  
>>>>>more use cases. If others think this extra complexity is not worth the  
>>>>>value its adding please raise your concerns so we can discuss if it  
>>>>>should  
>>>>>be removed from the acl structure. Note that even in absence of hosts  
>>>>>from  
>>>>>ACL users will still be able to whitelist/blacklist host as long as we  
>>>>>start supporting principalType = “host”, easy to add and can be an  
>>>>>incremental improvement. They will however loose the ability to  
>>>>>restrict  
>>>>>access to users just from a set of hosts.  
>>>>>  
>>>>>We agreed to offer a CLI to overcome the JSON acl config  
>>>>>https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorizati  
>>>>>on  
>>>>>+I  
>>>>>n  
>>>>>terface#KIP-11-AuthorizationInterface-AclManagement(CLI). I still like  
>>>>>Jsons but that probably has something to do with me being a developer  
>>>>>:-).  
>>>>>  
>>>>>Thanks  
>>>>>Parth  
>>>>>  
>>>>>On 4/22/15, 11:38 AM, "Jeff Holoman" <jholo...@cloudera.com> wrote:  
>>>>>  
>>>>>>Parth,  
>>>>>>  
>>>>>>This is a long thread, so trying to keep up here, sorry if this has  
>>>>>>been  
>>>>>>covered before. First, great job on the KIP proposal and work so far.  
>>>>>>  
>>>>>>Are we sure that we want to tie host level access to a given user? My  
>>>>>>understanding is that the ACL will be (omitting some fields)  
>>>>>>  
>>>>>>user_a, host1, host2, host3  
>>>>>>user_b, host1, host2, host3  
>>>>>>  
>>>>>>So there would potentially be a lot of redundancy in the configs.  
>>>>>>Does  
>>>>>>it  
>>>>>>make sense to have hosts be at the same level as principal in the  
>>>>>>hierarchy? This way you could just blanket the allowed / denied hosts  
>>>>>>and  
>>>>>>only have to worry about the users. So if you follow this, then  
>>>>>>  
>>>>>>we can wildcard the user so we can have a separate list of just  
>>>>>>host-based  
>>>>>>access. What's the order that the perms would be evaluated if a there  
>>>>>>was  
>>>>>>more than one match on a principal ?  
>>>>>>  
>>>>>>Is the thought that there wouldn't usually be much overlap on hosts?  
>>>>>>I  
>>>>>>guess I can imagine a scenario where I want to offline/online access  
>>>>>>to a  
>>>>>>particular hosts or set of hosts and if there was overlap, I'm doing  
>>>>>>a  
>>>>>>bunch of alter commands for just a single host. Maybe this is too  
>>>>>>contrived  
>>>>>>an example?  
>>>>>>  
>>>>>>I agree that having this level of granularity gives flexibility but I  
>>>>>>wonder if people will actually use it and not just * the hosts for a  
>>>>>>given  
>>>>>>user and create separate "global" list as i mentioned above?  
>>>>>>  
>>>>>>The only other system I know of that ties users with hosts for access  
>>>>>>is  
>>>>>>MySql and I don't love that model. Companies usually standardize on  
>>>>>>group  
>>>>>>authorization anyway, are we complicating that issue with the  
>>>>>>inclusion  
>>>>>>of  
>>>>>>hosts attached to users? Additionally I worry about the debt of big  
>>>>>>JSON  
>>>>>>configs in the first place, most non-developers find them  
>>>>>>non-intuitive  
>>>>>>already, so anything to ease this I think would be beneficial.  
>>>>>>  
>>>>>>  
>>>>>>Thanks  
>>>>>>  
>>>>>>Jeff  
>>>>>>  
>>>>>>On Wed, Apr 22, 2015 at 2:22 PM, Parth Brahmbhatt <  
>>>>>>pbrahmbh...@hortonworks.com> wrote:  
>>>>>>  
>>>>>>> Sorry I missed your last questions. I am +0 on adding ―host option  
>>>>>>>for  
>>>>>>> ―list, we could add it for symmetry. Again if this is only a CLI  
>>>>>>>change  
>>>>>>>it  
>>>>>>> can be added later if you mean adding this in authorizer interface  
>>>>>>>then  
>>>>>>>we  
>>>>>>> should make a decision now.  
>>>>>>>  
>>>>>>> Given a choice I would like to actually keep only one option which  
>>>>>>>is  
>>>>>>> resource based get (remove even the get based on principal). I see  
>>>>>>>those  
>>>>>>> (getAcl for principal or host) as special filtering case which can  
>>>>>>>easily  
>>>>>>> be achieved by a third party tool by doing "list all topics" and  
>>>>>>>calling  
>>>>>>> getAcls for each topic and applying filtering logic on that. I  
>>>>>>>really  
>>>>>>> don’t see the need to make those first class citizens of the  
>>>>>>>authorizer  
>>>>>>> interface given these kind of queries will be issued outside of  
>>>>>>>broker  
>>>>>>>JVM  
>>>>>>> so they will not benefit from the caching and because the storage  
>>>>>>>will  
>>>>>>>be  
>>>>>>> indexed on resource both these options even as a first class API  
>>>>>>>will  
>>>>>>>just  
>>>>>>> scan all topic acls and apply filtering logic.  
>>>>>>>  
>>>>>>> Thanks  
>>>>>>> Parth  
>>>>>>>  
>>>>>>> On 4/22/15, 11:08 AM, "Parth Brahmbhatt"  
>>>>>>><pbrahmbh...@hortonworks.com>  
>>>>>>> wrote:  
>>>>>>>  
>>>>>>> >Please see all the available options here  
>>>>>>> >  
>>>>>>>  
>>>>>>>https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authoriza  
>>>>>>>ti  
>>>>>>>on  
>>>>>>>+  
>>>>>>>I  
>>>>>>> >nterface#KIP-11-AuthorizationInterface-AclManagement(CLI) . I  
>>>>>>>think  
>>>>>>>it  
>>>>>>> >covers both hosts and operations and allows to specify a list for  
>>>>>>>both.  
>>>>>>> >  
>>>>>>> >Thanks  
>>>>>>> >Parth  
>>>>>>> >  
>>>>>>> >From: Tom Graves  
>>>>>>><tgraves...@yahoo.com<mailto:tgraves...@yahoo.com>>  
>>>>>>> >Reply-To: Tom Graves  
>>>>>>><tgraves...@yahoo.com<mailto:tgraves...@yahoo.com>>  
>>>>>>> >Date: Wednesday, April 22, 2015 at 11:02 AM  
>>>>>>> >To: Parth Brahmbhatt  
>>>>>>> ><pbrahmbh...@hortonworks.com<mailto:pbrahmbh...@hortonworks.com>>,  
>>>>>>> >"dev@kafka.apache.org<mailto:dev@kafka.apache.org>"  
>>>>>>> ><dev@kafka.apache.org<mailto:dev@kafka.apache.org>>  
>>>>>>> >Subject: Re: [DISCUSS] KIP-11- Authorization design for kafka  
>>>>>>>security  
>>>>>>> >  
>>>>>>> >Thanks for the explanations Parth.  
>>>>>>> >  
>>>>>>> >On the configs questions, the way I see it is its more likely to  
>>>>>>> >accidentally give everyone access, especially since you have to  
>>>>>>>run  
>>>>>>>a  
>>>>>>> >separate command to change the acls. If there was some config for  
>>>>>>> >defaults, a cluster admin could change that to be nobody or  
>>>>>>>certain  
>>>>>>>set  
>>>>>>> >of users, then grant others permissions. This would also remove  
>>>>>>>the  
>>>>>>>race  
>>>>>>> >between commands. This is something you can always add later  
>>>>>>>though  
>>>>>>>if  
>>>>>>> >people request it.  
>>>>>>> >  
>>>>>>> >So in kafka-acl.sh how do I actually tell it what the operation  
>>>>>>>is?  
>>>>>>> >kafka-acl.sh --topic testtopic --add --grandprincipal  
>>>>>>>user:joe,user:kate  
>>>>>>> >  
>>>>>>> >where does READ, WRITE, etc go? Can specify as a list so I don't  
>>>>>>>have  
>>>>>>>to  
>>>>>>> >run this a bunch of times for each.  
>>>>>>> >  
>>>>>>> >Do you want to have a --host option for --list so that admins  
>>>>>>>could  
>>>>>>>see  
>>>>>>> >what acls apply to specific host(s)?  
>>>>>>> >  
>>>>>>> >Tom  
>>>>>>> >  
>>>>>>> >  
>>>>>>> >  
>>>>>>> >On Wednesday, April 22, 2015 11:38 AM, Parth Brahmbhatt  
>>>>>>> ><pbrahmbh...@hortonworks.com<mailto:pbrahmbh...@hortonworks.com>>  
>>>>>>>wrote:  
>>>>>>> >  
>>>>>>> >  
>>>>>>> >  
>>>>>>> >FYI, I have modified the KIP to include group as resource. In  
>>>>>>>order  
>>>>>>>to  
>>>>>>> >access “joinGroup” and “commitOFfset” APIs the user will need a  
>>>>>>>read  
>>>>>>> >permission on topic and WRITE permission on group.  
>>>>>>> >  
>>>>>>> >I plan to open a VOTE thread by noon if there are no more  
>>>>>>>concerns.  
>>>>>>> >  
>>>>>>> >Thanks  
>>>>>>> >Parth  
>>>>>>> >  
>>>>>>> >On 4/22/15, 9:03 AM, "Tom Graves"  
>>>>>>>  
>>>>>>>><tgraves...@yahoo.com.INVALID<mailto:tgraves...@yahoo.com.INVALID>>  
>>>>>>> wrote:  
>>>>>>> >  
>>>>>>> >>Hey everyone,  
>>>>>>> >>Sorry to jump in on the conversation so late. I'm new to Kafka.  
>>>>>>>I'll  
>>>>>>> >>apologize in advance if you have already covered some of my  
>>>>>>>questions. I  
>>>>>>> >>read through the wiki and had some comments and questions.  
>>>>>>> >>1) public enum Operation needs EDIT changed to ALTER  
>>>>>>> >  
>>>>>>> >> Done.  
>>>>>>> >  
>>>>>>> >>2) Does the Authorizer class need a setAcls? Rather then just  
>>>>>>>add  
>>>>>>>to  
>>>>>>>be  
>>>>>>> >>able to set to explicit list and overwrite what was there? I see  
>>>>>>>the  
>>>>>>> >>kafka-acl.sh lists a removeall so I guess you could do removeall  
>>>>>>>and  
>>>>>>>then  
>>>>>>> >>add. I also don't see a removeall in the Authorizer class, is it  
>>>>>>>going  
>>>>>>> >>to loop through them all to remove each one?  
>>>>>>> >  
>>>>>>> > There is an overloaded version of removeAcls in the interface  
>>>>>>>that  
>>>>>>> >takes  
>>>>>>> >in resource as the only input and as described in the javadoc all  
>>>>>>>the  
>>>>>>>acls  
>>>>>>> >attached to that resource will be deleted. To cover the setAcl use  
>>>>>>>case  
>>>>>>> >the caller can first call remove and then add.  
>>>>>>> >  
>>>>>>> >>3) Can someone tell me what the use case to do acls based on the  
>>>>>>>hosts?  
>>>>>>> >>I can see some possibilities just wondering if we can concrete  
>>>>>>>ones  
>>>>>>>where  
>>>>>>> >>one user is allowed from one host but not another.  
>>>>>>> >  
>>>>>>> > I am not sure if I understand the question given the use case  
>>>>>>>you  
>>>>>>> >described in your question is what we are trying to cover with use  
>>>>>>>of  
>>>>>>> >hosts in Acl. There are some additional use cases like “allow  
>>>>>>>access  
>>>>>>>to  
>>>>>>> >any user from host1,host2” but I think primarily it gives the  
>>>>>>>admins  
>>>>>>>the  
>>>>>>> >ability to define acls at a more granular level.  
>>>>>>> >  
>>>>>>> >>4) I'm a bit unclear how the "resource" works in the Authorizer  
>>>>>>>class.  
>>>>>>> >>From what I see we have 2 resources - topics and cluster. If I  
>>>>>>>want  
>>>>>>>to  
>>>>>>> >>add an acl to allow "joe" to CREATE for the cluster then I call  
>>>>>>>addAcls  
>>>>>>> >>with Acl("user: joe", ALLOW, Set(*), Set(CREATE)) and "cluster"?  
>>>>>>>What  
>>>>>>> >>if I want to call addAcls for DESCRIBE on a topic? Is the  
>>>>>>>resource  
>>>>>>>then  
>>>>>>> >>"topic" or is it the topic name?  
>>>>>>> >  
>>>>>>> > We now have 3 resources(added group), please see the updated  
>>>>>>>doc.  
>>>>>>>The  
>>>>>>> >CREATE acl that you described is correct. For any topic operation  
>>>>>>>you  
>>>>>>> >should use topic name as the resource name and for group the user  
>>>>>>>will  
>>>>>>> >provide groupId as resource name.  
>>>>>>> >  
>>>>>>> >>5) reassigning partitions is a CLUSTER_ACTION or superuser? Its  
>>>>>>>not  
>>>>>>> >>totally clear to me the differences between these. what about  
>>>>>>>increasing  
>>>>>>> >># of partitions?  
>>>>>>> >  
>>>>>>> > I see this as an alter topic operation so it is at topic level  
>>>>>>>and  
>>>>>>>the  
>>>>>>> >user must have alter permissions on topic.  
>>>>>>> >  
>>>>>>> >>6) groups are mentioned, are we supporting right away or is that  
>>>>>>>a  
>>>>>>>follow  
>>>>>>> >>on item? (is there going to be a kafka.supergroups)  
>>>>>>> >  
>>>>>>> > I think it can be a separate jira just for braking down the  
>>>>>>>code  
>>>>>>> >review  
>>>>>>> >in smaller chunk. We will support it in first version but I think  
>>>>>>>if  
>>>>>>>we  
>>>>>>> >can not do it for any reason that should not block a release with  
>>>>>>>all  
>>>>>>>the  
>>>>>>> >other authZ work. We made deliberate design choices (like  
>>>>>>>introducing  
>>>>>>>a  
>>>>>>> >principalType in KafkaPrinciapl) to allow supporting groups as an  
>>>>>>> >incremental change.  
>>>>>>> >  
>>>>>>> >>7) Are there config options for setting acls when I create my  
>>>>>>>topic?  
>>>>>>>Or  
>>>>>>> >>do I have to create my topic and then run the kafka-acl.sh script  
>>>>>>>to  
>>>>>>>set  
>>>>>>> >>them? Although its very small, there would be possible race  
>>>>>>>there  
>>>>>>>that  
>>>>>>> >>someone could start producing to topic before acls are set.  
>>>>>>> >  
>>>>>>> > We discussed this yesterday and we agreed to go with  
>>>>>>>kafka-acl.sh.  
>>>>>>>Yes  
>>>>>>> >there is a very very small window of vulnerability but I think  
>>>>>>>that  
>>>>>>>really  
>>>>>>> >does not warrant to change the decision in this case.  
>>>>>>> >  
>>>>>>> >>8) are there configs for cluster level acl defaults? Or does it  
>>>>>>>default  
>>>>>>> >>to superusers on bringing up new cluster and you have to modify  
>>>>>>>with  
>>>>>>>cli.  
>>>>>>> >>thanks,Tom  
>>>>>>> >  
>>>>>>> > No defaults, the default is superusers will have full access.  
>>>>>>>I  
>>>>>>>don’t  
>>>>>>> >think making assumptions about ones security requirement should be  
>>>>>>>our  
>>>>>>> >burden.  
>>>>>>> >  
>>>>>>> >  
>>>>>>> >>  
>>>>>>> >> On Tuesday, April 21, 2015 7:10 PM, Parth Brahmbhatt  
>>>>>>> >><pbrahmbh...@hortonworks.com<mailto:pbrahmbh...@hortonworks.com>>  
>>>>>>>wrote:  
>>>>>>> >>  
>>>>>>> >>  
>>>>>>> >> I have added the notes to KIP-11 Open question sections.  
>>>>>>> >>  
>>>>>>> >>Thanks  
>>>>>>> >>Parth  
>>>>>>> >>  
>>>>>>> >>On 4/21/15, 4:49 PM, "Gwen Shapira"  
>>>>>>> >><gshap...@cloudera.com<mailto:gshap...@cloudera.com>> wrote:  
>>>>>>> >>  
>>>>>>> >>>Adding my notes from today's call to the thread:  
>>>>>>> >>>  
>>>>>>> >>>** Deny or Allow all by default? We will add a configuration to  
>>>>>>> >>>control this. The configuration will default to “allow” for  
>>>>>>>backward  
>>>>>>> >>>compatibility. Security admins can set it to "deny"  
>>>>>>> >>>  
>>>>>>> >>>** Storing ACLs for default authorizers: We'll store them in ZK.  
>>>>>>>We'll  
>>>>>>> >>>support pointing the authorizer to any ZK.  
>>>>>>> >>>The use of ZK will be internal to the default authorizer.  
>>>>>>>Authorizer  
>>>>>>> >>>reads ACLs from cache every hour. We proposed having mechanism  
>>>>>>> >>>(possibly via new ZK node) to tell broker to refresh the cache  
>>>>>>> >>>immediately.  
>>>>>>> >>>  
>>>>>>> >>>** Support deny as permission type - we agreed to keep this.  
>>>>>>> >>>  
>>>>>>> >>>** Mapping operations to API: We may need to add Group as a  
>>>>>>>resource,  
>>>>>>> >>>with JoinGroup and OffsetCommit require privilege on the  
>>>>>>>consumer  
>>>>>>> >>>group.  
>>>>>>> >>>This can be something we pass now and authorizers can support in  
>>>>>>> >>>future. - Jay will write specifics to the mailing list  
>>>>>>>discussion.  
>>>>>>> >>>  
>>>>>>> >>>On Tue, Apr 21, 2015 at 4:32 PM, Jay Kreps  
>>>>>>> >>><jay.kr...@gmail.com<mailto:jay.kr...@gmail.com>> wrote:  
>>>>>>> >>>> Following up on the KIP discussion. Two options for  
>>>>>>>authorizing  
>>>>>>> >>>>consumers  
>>>>>>> >>>> to read topic "t" as part of group "g":  
>>>>>>> >>>> 1. READ permission on resource /topic/t  
>>>>>>> >>>> 2. READ permission on resource /topic/t AND WRITE permission  
>>>>>>>on  
>>>>>>> >>>>/group/g  
>>>>>>> >>>>  
>>>>>>> >>>> The advantage of (1) is that it is simpler. The disadvantage  
>>>>>>>is  
>>>>>>>that  
>>>>>>> >>>>any  
>>>>>>> >>>> member of any group that reads from t can commit offsets as  
>>>>>>>any  
>>>>>>>other  
>>>>>>> >>>> member of a different group. This doesn't effect data security  
>>>>>>>(who  
>>>>>>> >>>>can  
>>>>>>> >>>> access what) but it is a bit of a management issue--a  
>>>>>>>malicious  
>>>>>>>person  
>>>>>>> >>>>can  
>>>>>>> >>>> cause data loss or duplicates for another consumer by  
>>>>>>>committing  
>>>>>>> >>>>offset.  
>>>>>>> >>>>  
>>>>>>> >>>> I think I favor (2) but it's worth it to think it through.  
>>>>>>> >>>>  
>>>>>>> >>>> -Jay  
>>>>>>> >>>>  
>>>>>>> >>>> On Tue, Apr 21, 2015 at 2:43 PM, Parth Brahmbhatt <  
>>>>>>> >>>>  
>>>>>>>pbrahmbh...@hortonworks.com<mailto:pbrahmbh...@hortonworks.com>>  
>>>>>>> >>>>wrote:  
>>>>>>> >>>>  
>>>>>>> >>>>> Hey Jun,  
>>>>>>> >>>>>  
>>>>>>> >>>>> Yes and we support wild cards for all acl entities principal,  
>>>>>>>hosts  
>>>>>>> >>>>>and  
>>>>>>> >>>>> operation.  
>>>>>>> >>>>>  
>>>>>>> >>>>> Thanks  
>>>>>>> >>>>> Parth  
>>>>>>> >>>>>  
>>>>>>> >>>>> On 4/21/15, 9:06 AM, "Jun Rao"  
>>>>>>> >>>>><j...@confluent.io<mailto:j...@confluent.io>> wrote:  
>>>>>>> >>>>>  
>>>>>>> >>>>> >Harsha, Parth,  
>>>>>>> >>>>> >  
>>>>>>> >>>>> >Thanks for the clarification. This makes sense. Perhaps we  
>>>>>>>can  
>>>>>>> >>>>>clarify the  
>>>>>>> >>>>> >meaning of those rules in the wiki.  
>>>>>>> >>>>> >  
>>>>>>> >>>>> >Related to this, it seems that we need to support wildcard  
>>>>>>>in  
>>>>>>> >>>>>cli/request  
>>>>>>> >>>>> >protocol for topics?  
>>>>>>> >>>>> >  
>>>>>>> >>>>> >Jun  
>>>>>>> >>>>> >  
>>>>>>> >>>>> >On Mon, Apr 20, 2015 at 9:07 PM, Parth Brahmbhatt <  
>>>>>>> >>>>>  
>>>>>>>>pbrahmbh...@hortonworks.com<mailto:pbrahmbh...@hortonworks.com>>  
>>>>>>> >>>>>wrote:  
>>>>>>> >>>>> >  
>>>>>>> >>>>> >> The iptables on unix supports the DENY operator, not that  
>>>>>>>it  
>>>>>>> >>>>>should  
>>>>>>> >>>>> >> matter. The deny operator can also be used to specify  
>>>>>>>³allow  
>>>>>>>user1  
>>>>>>> >>>>>to  
>>>>>>> >>>>> >>READ  
>>>>>>> >>>>> >> from topic1 from all hosts but host1,host2². Again we  
>>>>>>>could  
>>>>>>>add a  
>>>>>>> >>>>>host  
>>>>>>> >>>>> >> group semantic and extra complexity around that, not sure  
>>>>>>>if  
>>>>>>>its  
>>>>>>> >>>>>worth  
>>>>>>> >>>>> >>it.  
>>>>>>> >>>>> >> In addition with DENY operator you are now not forced to  
>>>>>>>create a  
>>>>>>> >>>>> >>special  
>>>>>>> >>>>> >> group just to support the authorization use case. I am not  
>>>>>>> >>>>>convinced  
>>>>>>> >>>>> >>that  
>>>>>>> >>>>> >> the operator it self is really all that confusing. There  
>>>>>>>are 3  
>>>>>>> >>>>>practical  
>>>>>>> >>>>> >> use cases:  
>>>>>>> >>>>> >> - Resource with no acl what so ever -> allow access to  
>>>>>>>everyone (  
>>>>>>> >>>>>just  
>>>>>>> >>>>> >>for  
>>>>>>> >>>>> >> backward compatibility, I would much rather fail close and  
>>>>>>>force  
>>>>>>> >>>>>users  
>>>>>>> >>>>> >>to  
>>>>>>> >>>>> >> explicitly grant acls that allows access to all users.)  
>>>>>>> >>>>> >> - Resource with some acl attached -> only users that have  
>>>>>>>a  
>>>>>>> >>>>>matching  
>>>>>>> >>>>> >>allow  
>>>>>>> >>>>> >> acl are allowed (i.e. ³allow READ access to topic1 to  
>>>>>>>user1  
>>>>>>>from  
>>>>>>> >>>>>all  
>>>>>>> >>>>> >> hosts², only user1 has READ access and no other user has  
>>>>>>>access of  
>>>>>>> >>>>>any  
>>>>>>> >>>>> >> kind)  
>>>>>>> >>>>> >> - Resource with some allow and some deny acl attached ->  
>>>>>>>users  
>>>>>>>are  
>>>>>>> >>>>> >>allowed  
>>>>>>> >>>>> >> to perform operation only when they satisfy allow acl and  
>>>>>>>do  
>>>>>>>not  
>>>>>>> >>>>>have  
>>>>>>> >>>>> >> conflicting deny acl. Users that have no acl(allow or  
>>>>>>>deny)  
>>>>>>>will  
>>>>>>> >>>>>still  
>>>>>>> >>>>> >>not  
>>>>>>> >>>>> >> have any access. (i.e. ³allow READ access to topic1 to  
>>>>>>>user1  
>>>>>>>from  
>>>>>>> >>>>>all  
>>>>>>> >>>>> >> hosts except host1 and host², only user1 has access but  
>>>>>>>not  
>>>>>>>from  
>>>>>>> >>>>>host1  
>>>>>>> >>>>> >>an  
>>>>>>> >>>>> >> host2)  
>>>>>>> >>>>> >>  
>>>>>>> >>>>> >> I think we need to make a decision on deny primarily  
>>>>>>>because  
>>>>>>>with  
>>>>>>> >>>>> >> introduction of acl management API, Acl is now a public  
>>>>>>>class  
>>>>>>>that  
>>>>>>> >>>>>will  
>>>>>>> >>>>> >>be  
>>>>>>> >>>>> >> used by Ranger/Santry and other authroization providers.  
>>>>>>>In  
>>>>>>> >>>>>Current  
>>>>>>> >>>>> >>design  
>>>>>>> >>>>> >> the acl has a permissionType enum field with possible  
>>>>>>>values  
>>>>>>>of  
>>>>>>> >>>>>Allow  
>>>>>>> >>>>> >>and  
>>>>>>> >>>>> >> Deny. If we chose to remove deny we can assume all acls to  
>>>>>>>be  
>>>>>>>of  
>>>>>>> >>>>>allow  
>>>>>>> >>>>> >> type and remove the permissionType field completely.  
>>>>>>> >>>>> >>  
>>>>>>> >>>>> >> Thanks  
>>>>>>> >>>>> >> Parth  
>>>>>>> >>>>> >>  
>>>>>>> >>>>> >> On 4/20/15, 6:12 PM, "Gwen Shapira"  
>>>>>>> >>>>><gshap...@cloudera.com<mailto:gshap...@cloudera.com>> wrote:  
>>>>>>> >>>>> >>  
>>>>>>> >>>>> >> >I think thats how its done in pretty much any system I  
>>>>>>>can  
>>>>>>>think  
>>>>>>> >>>>>of.  
>>>>>>> >>>>> >> >  
>>>>>>> >>>>> >>  
>>>>>>> >>>>> >>  
>>>>>>> >>>>>  
>>>>>>> >>>>>  
>>>>>>> >>  
>>>>>>> >>  
>>>>>>> >>  
>>>>>>> >>  
>>>>>>> >  
>>>>>>> >  
>>>>>>> >  
>>>>>>>  
>>>>>>>  
>>>>>>  
>>>>>>  
>>>>>>--  
>>>>>>Jeff Holoman  
>>>>>>Systems Engineer  
>>>>>  
>>>>  
>>  

Reply via email to