[
https://issues.apache.org/jira/browse/KAFKA-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318833#comment-15318833
]
Jason Gustafson commented on KAFKA-3797:
----------------------------------------
[~vahid] Feel free to take it, but we should probably give people a chance to
comment before choosing which way to go (or whether we need to do anything at
all). I personally would prefer to disallow clients from producing to that
topic entirely since it bypasses all checks that the coordinator can do for the
group. However, if there is really some use case that calls for it, then the
first option I suggested still seems reasonable and we should probably think
through whether changes are needed to the coordinator to ensure that the offset
cache stays in sync with the data. Currently, the coordinator would not see any
changes written to the offsets topic until the partitions change leaders.
> 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)
