Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Status

Current stateAccepted

Under Discussion thread: here

Discussion Vote thread: here and here

JIRA:

Jira
serverASF JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId5aa69414-a9e9-3523-82ec-879b028fb15b
keyKAFKA-5638

Released: 2.1.0

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

...

The anomaly is quite easy to spot in this table. All APIs require either Read or Describe operations on the Group resource type, except for ListGroups. The reason for originally choosing the Describe (Cluster) ACL over Describe (Group) is probably for admin type users who want to be able to take an inventory of all the consumer groups in the cluster (Describe (Cluster) could imply Describe (Group) for all groups in the cluster). Similar ACL setting exists for APIs such as DescribeAcls or DescribeLogDirs. However, there are some drawbacks to the current choice of ACL setting for ListGroups API:

  1. As long as a user has a Describe (Cluster) ACL permission s/he can list all groups in the cluster. This exposes a security risk: either a user cannot list consumer groups in the cluster or s/he can list all of them. Listing all groups is reasonable for a cluster administrator, but for other users what they can list should be limited to what they need to list.
  2. A user with Read access to a group can describe the group, but the same user would not see anything when listing groups (assuming there is no Describe access to the cluster). It makes more sense for this user to be able to list all groups s/he can already describe.

This would change the ACL requirements for ListGroups API in the table above (to return meaningful data) to Describe (Cluster) or Describe (Group). Not having any of these ACLs would still not cause any authorization error, but there will be no group in the response either. 

API
Minimum Required Permission
ListGroupsDescribe (Cluster) or Describe (Group)

Proposed Changes

The change proposed by this KIP is simple. An alternative ACL will be added as the minimum required permission of the ListGroups API: Describe (Cluster) would still work as before. However, a Describe (Group) ACL is added which gives users the ability to list groups they have this ACL on. The minimum required permissions are hard-coded in kafka.server.KafkaApis.scala inside each API handler method. For example, the part that enforces the minimum required permission for the ListGroups API currently looks like this:

...

  • Changing the minimum required ACL for ListGroups API from Describe (Cluster) to Describe (Group). This would have made it difficult or even impossible to get a listing of also work provided that cluster admins are given a wild card describe group permission so they can list all groups in the cluster, something that cluster admins should be able to easily perform. However, for the sake of backward compatibility the preference was given to the alternative, which preserves the describe cluster permission.