I will move the comments about subject versus principal wrt session to the PR above. The comments around keys, etc are more appropriate there.
If I tie this together with my comments in the thread on SASL / Kerberos, what I am having a hard time figuring out are the pluggable framework for both authentication and authorization versus implementation of specific authentication and authorization providers. As for caching decisions, it just seems silly to authorize on the same operation over and over again (e.g. publishing to the same topic), but perhaps if the ACLs are small enough this will be ok. On Fri, Apr 24, 2015 at 2:18 PM, Parth Brahmbhatt < pbrahmbh...@hortonworks.com> wrote: > Thanks for your comments Gari. My responses are inline. > > Thanks > Parth > > On 4/24/15, 10:36 AM, "Gari Singh" <gari.r.si...@gmail.com> wrote: > > >Sorry - fat fingered send ... > > > > > >Not sure if my "newbie" vote will count, but I think you are getting > >pretty > >close here. > > > >Couple of things: > > > >1) I know the Session object is from a different JIRA, but I think that > >Session should take a Subject rather than just a single Principal. The > >reason for this is because a Subject can have multiple Principals (for > >example both a username and a group or perhaps someone would want to use > >both the username and the clientIP as Principals) > > I think the user -> group mapping can be done at Authorization > implementation layer. In any case as you pointed out the session is part > of another jira and I think a PR is out > https://reviews.apache.org/r/27204/diff/ and we should discuss it on that > PR. > > > > >2) We would then also have multiple concrete Principals, e.g. > > > >KafkaPrincipal > >KafkaUserPrincipal > >KafkaGroupPrincipal > >(perhaps even KafkaKerberosPrincipal and KafkaClientAddressPrincipal) > >etc > > > >This is important as eventually (hopefully sooner than later), we will > >support multiple types of authentication which may each want to populate > >the Subject with one or more Principals and perhaps even credentials (this > >could be used in the future to hold encryption keys or perhaps the raw > >info > >prior to authentication). > > > >So in this way, if we have different authentication modules, we can add > >different types of Principals by extension > > > >This also allows the same subject to have access to some resources based > >on > >username and some based on group. > > > >Given that with this we would have different types of Principals, I would > >then modify the ACL to look like: > > > >{"version":1, > > {"acls":[ > > { > > "principal_types":["KafkaUserPrincipal","KafkaGroupPrincipal"], > > "principals":["alice","kafka-devs"] > > ....... > > > >or > > > >{"version":1, > > {"acls":[ > > { > > "principals":["KafkaUserPrincipal:alice","KafkaGroupPrincipal:kafka- > >devs"] > > > > > >But in either case this allows for easy identification of the type of > >principal and makes it easy to plugin multiple kinds of principals > > > >The advantage of all of this is that it now provides more flexibility for > >custom modules for both authentication and authorization moving forward. > > All the principals that you listed above can be supported with > current > design. Acls take a KafkaPrincipal as input which is a combination of type > and principal name and the authorizer implementations are free to create > any extension of this which covers group: groupName, host: HostName, > kerberos: kerberosUserName and any other types that may come up. I am not > sure how encryption key storage is relavent to the Authorizer so will be > great if you can elaborate. > > > > >3) Are you sure that you want "authorize" to take a "session" object? If > >we use the model in one above, we could just populate the Subject with a > >KafkaClientAddressPrincipal and thenhave access to that when evaluated the > >ACLs. > > I think it is better to take a session which can just be a wrapper > on top > of Subject + host for now. This allows for extension which in my opinion > is more "future requirement" proof. > > > > >4) What about actually caching authorization decisions? I know ACLs will > >be cached, but the actual authorize decision can be expensive as well? > > In default implementation I don’t plan to do this. Easy to add > later if > we want to but I am not sure why would this ever be expansive when acls > are cached and number of acls on a single topic should be very small and > iterating over them with simple string comparison should not really be > expansive. > > Thanks > Parth > > > > >On Fri, Apr 24, 2015 at 1:27 PM, Gari Singh <gari.r.si...@gmail.com> > >wrote: > > > >> Not sure if my "newbie" vote will count, but I think you are getting > >> pretty close here. > >> > >> Couple of things: > >> > >> 1) I know the Session object is from a different JIRA, but I think that > >> Session should take a Subject rather than just a single Principal. The > >> reason for this is because a Subject can have multiple Principals (for > >> example both a username and a group or perhaps someone would want to use > >> both the username and the clientIP as Principals) > >> > >> 2) We would then also have multiple concrete Principals, e.g. > >> > >> KafkaPrincipal > >> KafkaUserPrincipal > >> KafkaGroupPrincipal > >> (perhaps even KafkaKerberosPrincipal and KafkaClientAddressPrincipal) > >> etc > >> > >> This is important as eventually (hopefully sooner than later), we will > >> support multiple types of authentication which may each want to populate > >> the Subject with one or more Principals and perhaps even credentials > >>(this > >> could be used in the future to hold encryption keys or perhaps the raw > >>info > >> prior to authentication). > >> > >> So in this way, if we have different authentication modules, we can add > >> different types of Principals by extension > >> > >> This also allows the same subject to have access to some resources based > >> on username and some based on group. > >> > >> Given that with this we would have different types of Principals, I > >>would > >> then modify the ACL to look like: > >> > >> {"version":1, > >> {"acls":[ > >> { > >> "principal_types":["KafkaUserPrincipal","KafkaGroupPrincipal"], > >> "principals":["alice","kafka-devs" > >> > >> > >> > >> > >> > >> 3) The advantage of all of this is that it now provides more flexibility > >> for custom modules for both authentication and authorization moving > >>forward. > >> > >> > >> > >> On Fri, Apr 24, 2015 at 12:37 PM, 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+-+Authorization > >>>+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+-+Authorization > >>> >>>>+ > >>> >>>>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 > >>> >> > >>> > > >>> > >> > >> > >
