[jira] [Updated] (KAFKA-4585) Offset fetch and commit requests use the same permissions

["Vahid Hashemian (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KAFKA-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vahid Hashemian updated KAFKA-4585:
-----------------------------------
    Labels: kip  (was: needs-kip)

> 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: 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.4.14#64029)