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