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
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?
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.
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?
5) reassigning partitions is a CLUSTER_ACTION or superuser? Its not totally
clear to me the differences between these. what about increasing # of
partitions?
6) groups are mentioned, are we supporting right away or is that a follow on
item? (is there going to be a kafka.supergroups)
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.
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
On Tuesday, April 21, 2015 7:10 PM, Parth Brahmbhatt
<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> 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.
>>> >> >
>>> >>
>>> >>
>>>
>>>
