Hi Dong, Thanks for your message.
My driving point for this KIP was a -seemingly- broken logic rather than a particular use case. I also considered the semantics of the ListGroups API and its expected behavior: To me, a user who can fetch/commit offsets in some consumer groups should be able to run ListGroups and see those groups (and nothing else) in the result. This expected behavior conveys (kind of) a use case by itself. Regarding your second question, I see the external service for managing ACLs should not be directly concerned with any Kafka specific functionality. Plus, as Ismael mentioned, we already implement something very similar for the TopicMetadataRequest API (when metadata of all topics is requested). Thanks again for reviewing the KIP closely and sharing your feedback. Regards. --Vahid From: Dong Lin <lindon...@gmail.com> To: dev@kafka.apache.org Date: 12/04/2017 04:52 PM Subject: Re: [DISCUSS] KIP-231: Improve the Required ACL of ListGroups API Hey Vahid, Thank you for the explanation. I am still wondering whether you have a specific use-case for user to be able to list the groups for which he/she has Describe access. I tried to think through this but couldn't find a specific use-case for this feature yet. I understand that admin of the Kafka cluster may want to know the number of consumer groups in the cluster because the number of consumer groups can affect the performance of the Kafka service. But this motivation does not hold for non-admin user. I image that a typical user probably already knows the group it wants to access, in which case he/she can use DescribeGroupsRequest to query the information of this group. On the other hand, if user does not already know the list of groups it has access it, I don't know how user is going to use this information after he/she is given a list of strings as the group Id. Could you help me understand whether there is use-case for this feature? Alternatively, maybe this KIP is solely driven by the idea that user should be able to list the groups for which he/she has Describe access. In this case, do you think it would be reasonable for the external service which is used to store the ACL to provide this capability of query groupId list based on the user credential? Thanks, Dong On Mon, Dec 4, 2017 at 3:42 PM, Vahid S Hashemian <vahidhashem...@us.ibm.com > wrote: > Hi Dong, > > Thanks for reviewing the KIP and providing your feedback. > > As you mentioned, the KIP suggests a modification to the semantics of > ListGroupResponse. > The main reason for submitting the KIP and suggesting a modification is > that there are issues with the current one (further explained in the KIP): > 1) listing groups is an all or nothing action, and 2) a Read access on a > group does not mean the user can list that group. > > I understand the solution outlined in the KIP may not be the best one, and > I have been debating that myself even after opening it up for discussion. > That solution was the one discussed with Jason on the corresponding JIRA. > I would also prefer an authorization > error in case none of the two accesses are in place, which should, at > least, partially address your concern (the ACL would filter, but would > also return authorization errors if needed). If you can think of something > on that front please let me know. > > Regarding the use case you asked for: if I'm just a user in the cluster > sharing it with other users, I should be able to see the groups of my > consumers without being exposed to other users' groups in the cluster. > > I hope I addressed your concerns. If I did not, or if I missed anything, > please let me know. Thanks. > > Regards. > --Vahid > > > > > From: Dong Lin <lindon...@gmail.com> > To: dev@kafka.apache.org > Date: 12/04/2017 01:43 PM > Subject: Re: [DISCUSS] KIP-231: Improve the Required ACL of > ListGroups API > > > > I forgot another question. Can you provide a use-case where a user wants > to > list all groups for which he/she has the Describe access? > > Thanks, > Dong > > > On Mon, Dec 4, 2017 at 1:40 PM, Dong Lin <lindon...@gmail.com> wrote: > > > Hey Vahid, > > > > Thanks for the KIP. If I understand the you correctly, you want client > to > > be able to list all the groups for which it currently has the describe > > access. > > > > As of now the ListGroupRequest does not allow user to specify the group. > > If user does not have the Describe Cluster access, ListGroupResponse > will > > return error. This KIP proposes to change the semantics of > > ListGroupsResponse such that ListGroupResponse will return the subset of > > groups for which the user has the Describe access. And if the does not > have > > Describe access to any group, ListGroupResponse will return an empty > list > > with no error. > > > > In my opinion this changes the semantics of ListGroupsResponse in a > > counter-intuitive way. Usually we use the ACL to determine whether the > > operation on the specified object can be performed or not. The response > > should provide either an error message or the result for the specified > > object. I couldn't remember a case where the ACL is used to filter the > > result without providing error. Do you think this could be a problem for > > this KIP? > > > > Thanks, > > Dong > > > > > > On Wed, Nov 29, 2017 at 3:18 PM, Vahid S Hashemian < > > vahidhashem...@us.ibm.com> wrote: > > > >> Completing the subject line :) > >> > >> > >> > >> From: "Vahid S Hashemian" <vahidhashem...@us.ibm.com> > >> To: dev <dev@kafka.apache.org> > >> Date: 11/29/2017 03:17 PM > >> Subject: [DISCUSS] KIP-231: > >> > >> > >> > >> Hi everyone, > >> > >> I started KIP-231 to propose a small change to the required ACL of > >> ListGroups API (in response to KAFKA-5638): > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.a > >> pache.org_confluence_display_KAFKA_KIP-2D231-253A-2BImprove- > >> 2Bthe-2BRequired-2BACL-2Bof-2BListGroups-2BAPI&d=DwIFAg&c=jf > >> _iaSHvJObTbx-siA1ZOg&r=Q_itwloTQj3_xUKl7Nzswo6KE4Nj-kjJc7uSV > >> cviKUc&m=XjHVTsIl7t-z0NBesB0U-ptMMm6mmpy3UqS8TjJM5yM&s=eu378 > >> oaLvC0Wzbfcz15Rwo4nqdrO11ENLK6v9Kq9Z6w&e= > >> > >> Your feedback and suggestions are welcome! > >> > >> Thanks. > >> --Vahid > >> > >> > >> > >> > >> > >> > >> > > > > > > >
