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> 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> 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> wrote: >> >> >I think thats how its done in pretty much any system I can think of. >> > >> >>
