Hi Chia-Ping, Makes sense. I guess you'll find whether that's a viable approach and that information will guide the final direction for the KIP.
Thanks, Andrew On 2026/04/19 13:26:07 Chia-Ping Tsai wrote: > hi Andrew > > I feel the truly tricky part is that the server currently returns only the > groups having custom configs, but in contrast, it returns all topic names > even if they have no custom configs. > > This is exactly my concern: relying on DESCRIBE_CONFIGS here essentially > empowers it to act as a DESCRIBE permission for listing all topic names, > which leads to a permission leak. > > If we want to strictly align the requirement with DESCRIBE_CONFIGS (as > suggested), then another change that must be included is that the server > should be modified to filter and return only the topic names that actually > have custom configs. > > I opened https://issues.apache.org/jira/browse/KAFKA-20487 to add more tests > for such behavior and enhance the docs. The remaining parts could be left to > this KIP > > Best, > Chia-Ping > > On 2026/04/13 16:49:51 Andrew Schofield wrote: > > Hi Kuan-Po Tseng, > > This is probably going to be a tricky KIP. Trying to resolve historical > > behaviour is always painful. > > > > I think the key here is to realise that this KIP is for listing the > > resources which have configuration, and that's not the same as listing the > > resources. The user is going to need DESCRIBE_CONFIGS on the specific > > topics and groups in order to discover the configuration values themselves, > > so if this RPC requires the same permission in order to list the resources > > for which they can describe the configs, that seems OK to me. > > > > In KIP-1000, we require DESCRIBE_CONFIGS on the CLUSTER to find a list of > > the client-metrics configs. > > > > In KIP-1142, there was no change and it's necessary to have > > DESCRIBE_CONFIGS on the CLUSTER to list the resources of all supported > > types. > > > > If you look at the ListGroups RPC, the user can list all groups if they > > have DESCRIBE on the CLUSTER. If they do not, they can only see the groups > > for which they have DESCRIBE on the GROUP. > > > > For this KIP, why couldn't we do a similar thing? If the user has > > DESCRIBE_CONFIGS on the CLUSTER, they can see all of the resources which > > have configs. If they do not, they can only see the resources for which > > they have specific DESCRIBE_CONFIGS. > > > > Thanks, > > Andrew > > > > On 2026/04/06 15:28:17 Chia-Ping Tsai wrote: > > > hi Viquar > > > > > > Thanks for updating the KIP numbers. This helps keep things organized. > > > > > > Best, > > > Chia-Ping > > > > > > On 2026/04/06 05:53:06 vaquar khan wrote: > > > > Hi Chia-Ping , > > > > > > > > As discussed I have updated my KIP with 1316 and 1317. > > > > > > > > Regards, > > > > Viquar Khan > > > > > > > > On Mon, 6 Apr 2026 at 00:32, Chia-Ping Tsai <[email protected]> wrote: > > > > > > > > > hi Viquar > > > > > > > > > > > It is each owner’s responsibility to ensure their KIP number does > > > > > > not > > > > > override an existing one. > > > > > > > > > > Just a gentle reminder that the process mentions we should "Update > > > > > the next > > > > > available KIP number below". You can find the details here: > > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=50859233#KafkaImprovementProposals-Process > > > > > > > > > > It is totally fine to have an occasional conflict with one KIP. > > > > > However, it > > > > > seems several KIPs were created without incrementing the number, > > > > > which has > > > > > unfortunately caused conflicts for several other contributors. > > > > > > > > > > Would you mind updating your KIP numbers instead? If you have any > > > > > questions > > > > > or concerns, please let me know. > > > > > > > > > > Best, > > > > > Chia-Ping > > > > > > > > > > vaquar khan <[email protected]> 於 2026年4月6日週一 下午12:49寫道： > > > > > > > > > > > Hi Kaun, > > > > > > > > > > > > Please search(search box) the current KIP list to verify that your > > > > > > assigned number does not already exist. If you find a conflict, > > > > > > check the > > > > > > creation dates; if your KIP was created later, please update it to a > > > > > > unique, available number. > > > > > > > > > > > > It is each owner’s responsibility to ensure their KIP number does > > > > > > not > > > > > > override an existing one. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Viquar Khan > > > > > > > > > > > > > > > > > > On Sun, Apr 5, 2026, 11:24 PM Chia-Ping Tsai <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > hi all, > > > > > > > > > > > > > > Just a gentle reminder: please remember to increment the "Next KIP > > > > > > Number" > > > > > > > after taking a number. This will help avoid potential conflicts. > > > > > > > > > > > > > > Best, > > > > > > > Chia-Ping > > > > > > > > > > > > > > Kuan-Po Tseng <[email protected]> 於 2026年4月6日週一 下午12:18寫道： > > > > > > > > > > > > > > > Hi Vaquar — I checked the Kafka Improvement Proposals > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals > > > > > > > > > > > > > > > > > page and don't see another KIP using 1298. > > > > > > > > Could you pick the next available KIP number and update > > > > > > > > accordingly? > > > > > > > > > > > > > > > > On Mon, Apr 6, 2026 at 12:10 PM vaquar khan > > > > > > > > <[email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > > Could you please correct Kip 1298 , we already have same no , > > > > > > > > > I > > > > > > created > > > > > > > > few > > > > > > > > > weeks back. > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Viquar Kha > > > > > > > > > > > > > > > > > > On Sun, Apr 5, 2026, 10:34 PM Kuan Po Tseng > > > > > > > > > <[email protected]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Thanks again for the input! > > > > > > > > > > > > > > > > > > > > chia_01: Sure, we can add a debug message on the server > > > > > > > > > > side when > > > > > > > > > response > > > > > > > > > > is empty and using v2 with only DESCRIBE_CONFIGS on CLUSTER > > > > > > > > > > and > > > > > > > > DESCRIBE > > > > > > > > > on > > > > > > > > > > CLUSTER not set. Additionally, I think it would be helpful > > > > > > > > > > to > > > > > add a > > > > > > > > > warning > > > > > > > > > > message in ConfigCommand when the LIST_CONFIG_RESOURCE API > > > > > response > > > > > > > is > > > > > > > > > > empty, to let users know they may need to update their ACL. > > > > > > > > > > > > > > > > > > > > On 2026/04/05 08:55:06 Chia-Ping Tsai wrote: > > > > > > > > > > > chia_01: Regarding the migration plan, I have a concern > > > > > > > > > > > about > > > > > > > > potential > > > > > > > > > > user confusion. Since clients using v2 with only > > > > > > > > > > DESCRIBE_CONFIGS > > > > > > > will > > > > > > > > > > receive an empty response rather than an authorization > > > > > > > > > > error, > > > > > this > > > > > > > > silent > > > > > > > > > > failure might be very hard to debug. Should we consider > > > > > > > > > > logging a > > > > > > > > warning > > > > > > > > > > message in this specific scenario to help users identify the > > > > > > missing > > > > > > > > > > DESCRIBE ACL? > > > > > > > > > > > > > > > > > > > > > > On 2026/04/05 03:48:16 Kuan-Po Tseng wrote: > > > > > > > > > > > > Thanks for the feedback, Chia-Ping! > > > > > > > > > > > > > > > > > > > > > > > > chia_00: That's a fair point. I'm a bit hesitant to > > > > > > > > > > > > handle > > > > > > > > > > DESCRIBE_CONFIGS > > > > > > > > > > > > in handleTopicMetadataRequest and > > > > > > > > > > > > handleListGroupsRequest, > > > > > > > > > > > > since those APIs return more than just names. Exposing > > > > > > > topic/group > > > > > > > > > > names > > > > > > > > > > > > based on a config-oriented permission feels semantically > > > > > > > > misaligned, > > > > > > > > > > > > and I'm not sure it adds much value. > > > > > > > > > > > > Another approach worth considering: we could bump the > > > > > > > > > > > > API > > > > > > version > > > > > > > > of > > > > > > > > > > > > LIST_CONFIG_RESOURCES and switch to DESCRIBE instead of > > > > > > > > > > > > DESCRIBE_CONFIGS, aligning it with other > > > > > > > > > > > > resource-related > > > > > APIs. > > > > > > > > > > > > > > > > > > > > > > > > I’ll update the KIP later, and would love to hear > > > > > > > > > > > > others' > > > > > > > thoughts > > > > > > > > on > > > > > > > > > > this! > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 5, 2026 at 12:52 AM Chia-Ping Tsai < > > > > > > > > [email protected]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > chia_00: For the sake of consistency, if we permit > > > > > > > > DESCRIBE_CONFIGS > > > > > > > > > > to > > > > > > > > > > > > > expose topic and group names in LIST_CONFIG_RESOURCES, > > > > > should > > > > > > > we > > > > > > > > > > also align > > > > > > > > > > > > > handleTopicMetadataRequest and > > > > > > > > > > > > > handleListGroupsRequest? > > > > > > > > Currently, > > > > > > > > > > they > > > > > > > > > > > > > strictly require DESCRIBE. > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/04/04 16:40:08 Kuan-Po Tseng wrote: > > > > > > > > > > > > > > Hello everyone, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would like to start a discussion thread on > > > > > > > > > > > > > > KIP-1298 > > > > > which > > > > > > > > fixes > > > > > > > > > > an > > > > > > > > > > > > > > authorization inconsistency in > > > > > > > > > > > > > > LIST_CONFIG_RESOURCES. > > > > > Today > > > > > > > the > > > > > > > > > RPC > > > > > > > > > > > > > > requires DESCRIBE_CONFIGS on CLUSTER for all > > > > > > > > > > > > > > resource > > > > > > types, > > > > > > > > > which > > > > > > > > > > is > > > > > > > > > > > > > > stricter than comparable RPCs like LIST_GROUPS and > > > > > > METADATA. > > > > > > > > The > > > > > > > > > > > > > practical > > > > > > > > > > > > > > impact is that `kafka-configs.sh --describe > > > > > > > > > > > > > > --entity-type > > > > > > > > groups` > > > > > > > > > > > > > silently > > > > > > > > > > > > > > returns incomplete results for users holding > > > > > > > > > > > > > > DESCRIBE but > > > > > > not > > > > > > > > > > > > > > DESCRIBE_CONFIGS on CLUSTER. > > > > > > > > > > > > > > > > > > > > > > > > > > > > More details, please check > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/x/ZJI8G > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Kuan-Po Tseng > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
