Status
Current state: Accepted
Discussion thread: here
JIRA:
Released: 2.1.0
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Note: The discussion in this KIP applies to Java based (new) consumer only as the security feature is not supported by the old consumer.
From an authorization and ACL point of view, three operations (permission types) are currently defined for consumer groups: Describe, Read, All (a Delete operation is proposed by KIP-229). By default, Read implies Describe, and All implies all the other operations. Current consumer group related APIs and their minimum required permissions are listed in the following table:
API | Minimum Required Permission |
---|---|
DescribeGroup | Describe (Group) |
FindCoordinator | Describe (Group) |
Heartbeat | Read (Group) |
JoinGroup | Read (Group) |
LeaveGroup | Read (Group) |
ListGroups | Describe (Cluster) |
OffsetCommit | Read (Group) |
OffsetFetch | Describe (Group) |
SyncGroup | Read (Group) |
AddOffsetsToTxn | Read (Group) |
TxnOffsetCommit | Read (Group) |
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:
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 |
---|---|
ListGroups | Describe (Cluster) or Describe (Group) |
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:
if (!authorize(request.session, Describe, Resource.ClusterResource)) { sendResponseMaybeThrottle(request, requestThrottleMs => request.body[ListGroupsRequest].getErrorResponse(requestThrottleMs, Errors.CLUSTER_AUTHORIZATION_FAILED.exception)) } |
This KIP proposes to improve this implementation:
In general, Describe (Cluster) ACL should be given to cluster administrators only.
ListGroups
API from Describe (Cluster) to Describe (Group). This would also work provided that cluster admins are given a wild card describe group permission so they can list all groups in the cluster. However, for the sake of backward compatibility the preference was given to the alternative, which preserves the describe cluster permission.