kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Palino (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-3797) Improve security of __consumer_offsets topic
Date Tue, 07 Jun 2016 16:49:21 GMT

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

Todd Palino commented on KAFKA-3797:

I think the first option is more reasonable, and provides sufficient security. I can see cases
where you might want to have an external tool for changing a group's committed offsets.

> 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

View raw message