Table of Contents |
---|
Status
Current state: "Under Discussion" Accepted
Discussion thread: here
JIRA:
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Released: 1.0.0
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
...
Code Block | ||
---|---|---|
| ||
// this test is to clarify that the issue exists for the consumer group command line only, and not the API @Test def testDescribeGroupApiWithGroupDescribe() { addAndVerifyAcls(Set(new Acl(KafkaPrincipal.ANONYMOUS, Allow, Acl.WildCardHost, Describe)), groupResource) addAndVerifyAcls(Set(new Acl(KafkaPrincipal.ANONYMOUS, Allow, Acl.WildCardHost, Describe)), topicResource) AdminClient.createSimplePlaintext(brokerList).describeConsumerGroup(group) } // this test highlights the issue with command line, where the supposedly sufficient 'Describe' access is not enough to run the command @Test(expected = classOf[GroupAuthorizationException]) def testDescribeGroupCliWithGroupDescribe() { addAndVerifyAcls(Set(new Acl(KafkaPrincipal.ANONYMOUS, Allow, Acl.WildCardHost, Describe)), groupResource) addAndVerifyAcls(Set(new Acl(KafkaPrincipal.ANONYMOUS, Allow, Acl.WildCardHost, Describe)), topicResource) val cgcArgs = Array("--bootstrap-server", brokerList, "--describe", "--group", group) val opts = new ConsumerGroupCommandOptions(cgcArgs) val consumerGroupService = new KafkaConsumerGroupService(opts) consumerGroupService.describeGroup() } // this test confirms that a minimum of 'Read' access is required to successfully run the command @Test def testDescribeGroupCliWithGroupRead() { addAndVerifyAcls(Set(new Acl(KafkaPrincipal.ANONYMOUS, Allow, Acl.WildCardHost, Read)), groupResource) addAndVerifyAcls(Set(new Acl(KafkaPrincipal.ANONYMOUS, Allow, Acl.WildCardHost, Describe)), topicResource) val cgcArgs = Array("--bootstrap-server", brokerList, "--describe", "--group", group) val opts = new ConsumerGroupCommandOptions(cgcArgs) val consumerGroupService = new KafkaConsumerGroupService(opts) consumerGroupService.describeGroup() } |
Proposed Changes
The change proposed by this KIP is very simple: to lower the minimum required permission of the OffsetFetch
API from Read to Describe. These 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 OffsetFetch
API currently looks like this:
...
Code Block | ||
---|---|---|
| ||
if (!authorize(request.session, Describe, new Resource(Group, offsetFetchRequest.groupId)))
offsetFetchRequest.getErrorResponse(requestThrottleMs, Errors.GROUP_AUTHORIZATION_FAILED) |
Additional Food for Thought
As I was experimenting with the ACLs for this KIP I made some observations that made me wonder about the rationale behind their current ACL settings; and whether they need adjustments too:
Users can see all groups in the cluster (using consumer group’s --list
option) provided that they have Describe access to the cluster. Would it make sense to modify that experience and limit what is listed in the output to only those groups they have Describe access to? The reason is, almost anything else is accessible by a user only if the access is specifically granted (through ACL --add
); and this scenario should not be an exception. The potential change would be updating the minimum required permission of ListGroup
from Describe (Cluster) to Describe (Group), which means the implementation of KafkaApis.handleListGroupsRequest
would change from
...
language | scala |
---|
...
_AUTHORIZATION_FAILED |
...
to something like this:
...
language | scala |
---|
...
) |
...
We can also look at this issue from a different angle: A user with Read access to a group can describe the group, but the same user would not see anything when listing groups (not without a Describe access to the cluster). It makes more sense for this user to be able to list all groups s/he can already describe.
Compatibility, Deprecation, and Migration Plan
- A user that already has Read permission to a consumer group, with this change, would still be able to query the group like before (Read implies Describe). For this user the change is backward compatible.
- Consider a user with Describe access. The group Describe access implies access to
DescribeGroup
andFindCoordinator
APIs; even though this user cannot make use ofDescribeGroup
, as explained above. Giving this user access toOffsetFetch
API means fixing that broken experience.
In general, As a result of this change, Kafka admins may need to revisit the relevant ACLs and update them if necessary.
Rejected Alternatives