[
https://issues.apache.org/jira/browse/KAFKA-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321678#comment-15321678
]
Jason Gustafson commented on KAFKA-3797:
----------------------------------------
[~toddpalino] That might make the most sense, but I don't think you could
currently expect reasonable behavior if an admin tool tried to overwrite
offsets for a group since:
1. Writes directly to the topic are not reflected in the offset cache until a
change of leadership.
2. Even if they were, an active consumer wouldn't see the new offset until
after the next rebalance.
I also wonder if the external tool could just use the offset API directly in
this case?
> 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
> Assignee: Vahid Hashemian
>
> 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)
