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