[
https://issues.apache.org/jira/browse/KAFKA-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16025746#comment-16025746
]
Ewen Cheslack-Postava commented on KAFKA-4585:
----------------------------------------------
[~vahid] Honestly not sure -- there are a number of permissions that I find odd
choices, especially in the consumer. Unfortunately I didn't participate in the
discussions/patches that introduced those, so I'm not sure of the reasoning.
I've discussed this previously with [~hachikuji] and iirc he also agreed some
of them may seem a bit odd. Not sure if he has anything more to add here wrt
your specific question though.
> Offset fetch and commit requests use the same permissions
> ---------------------------------------------------------
>
> Key: KAFKA-4585
> URL: https://issues.apache.org/jira/browse/KAFKA-4585
> Project: Kafka
> Issue Type: Bug
> Components: consumer
> Affects Versions: 0.10.1.1
> Reporter: Ewen Cheslack-Postava
> Assignee: Vahid Hashemian
> Labels: needs-kip
>
> Currently the handling of permissions for consumer groups seems a bit odd
> because most of the requests use the Read permission on the Group (join,
> sync, heartbeat, leave, offset commit, and offset fetch). This means you
> cannot lock down certain functionality for certain users. For this issue I'll
> highlight a realistic issue since conflating the ability to perform most of
> these operations may not be a serious issue.
> In particular, if you want tooling for monitoring offsets (i.e. you want to
> be able to read from all groups) but don't want that tool to be able to write
> offsets, you currently cannot achieve this. Part of the reason this seems odd
> to me is that any operation which can mutate state seems like it should be a
> Write operation (i.e. joining, syncing, leaving, and committing; maybe
> heartbeat as well). However, [~hachikuji] has mentioned that the use of Read
> may have been intentional. If that is the case, changing at least offset
> fetch to be a Describe operation instead would allow isolating the mutating
> vs non-mutating request types.
> Note that this would require a KIP and would potentially have some
> compatibility implications. Note however, that if we went with the Describe
> option, Describe is allowed by default when Read, Write, or Delete are
> allowed, so this may not have to have any compatibility issues (if the user
> previously allowed Read, they'd still have all the same capabilities as
> before).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
