Table of Contents |
---|
Status
Current state: Accepted
Under Discussion thread: here
Discussion Vote thread: here and here
JIRA:
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Released: 2.1.0
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
...
- 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.
- 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
row 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) |
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.