...
Note: The discussion in this KIP applies to Java based (new) consumer only as the security feature is not supported by the old consumer does not have the security feature.
From an authorization and ACL point of view, three operations (permission types) are defined for consumer groups: Describe, Read, All. By default, Read implies Describe, and All implies all the other operations.
Currently, Current consumer group related APIs and their minimum required permission type 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) |
ListGroup | Describe (Cluster) |
OffsetCommit | Read (Group) |
OffsetFetch | Read (Group) |
SyncGroup | Read (Group) |
AddOffsetsToTxn | Read (Group) |
TxnOffsetCommit | Read (Group) |
...
The pattern we can see in this table is that a minimum Read permission is used for mutating APIs, whereas a minimum Describe permission is used for non-mutating APIs. The only One exception to this pattern is OffsetFetch, which is a non-mutating API, but requires a Read access. A Read access requirement for OffsetFetch is too restrictive, and unnecessary. Consider the following example by @ewencp in the corresponding JIRA's description: If we want to write a tool that only monitors offsets (no commits), we cannot achieve it with the current ACL settings. Because accessing the OffsetFetch API requires a Read permission; but a Read permission means we are also authorized to use the CommitOffset API (side note: for this tool to be able to read offsets of a group, it needs to have Describe access to the topics the group is consuming from. In other words, the tool will be able to see offsets of all topics (topic partitions) in the group it has Describe access to).
...