[jira] [Commented] (KAFKA-3797) Improve security of __consumer_offsets topic

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

    [ https://issues.apache.org/jira/browse/KAFKA-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15317835#comment-15317835 ] 

Vahid Hashemian commented on KAFKA-3797:
----------------------------------------

[~hachikuji] I can take this on if you don't mind.

> Improve security of __consumer_offsets topic
> --------------------------------------------
>
>                 Key: KAFKA-3797
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3797
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Jason Gustafson
>
> By default, we allow clients to override committed offsets and group metadata using the Produce API as long as they have Write access to the __consumer_offsets topic. From one perspective, this is fine: administrators can restrict access to this topic to trusted users. From another, it seems less than ideal for Write permission on that topic to subsume Group-level permissions for the full cluster. With this access, a user can cause all kinds of mischief including making the group "lose" data by setting offsets ahead of the actual position. This is probably not obvious to administrators who grant access to topics using a wildcard and it increases the risk from incorrectly applying topic patterns (if we ever add support for them). It seems reasonable to consider safer default behavior:
> 1. A simple option to fix this would be to prevent wildcard topic rules from applying to internal topics. To write to an internal topic, you need a separate rule which explicitly grants authorization to that topic.
> 2. A more extreme and perhaps safer option might be to prevent all writes to this topic (and potentially other internal topics) through the Produce API. Do we have any use cases which actually require writing to __consumer_offsets? The only potential case that comes to mind is replication.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)