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