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