You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Jason Gustafson (JIRA)" <ji...@apache.org> on 2016/10/01 06:09:20 UTC

[jira] [Updated] (KAFKA-3396) Unauthorized topics are returned to the user

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

Jason Gustafson updated KAFKA-3396:
-----------------------------------
    Resolution: Fixed
        Status: Resolved  (was: Patch Available)

Issue resolved by pull request 1908
[https://github.com/apache/kafka/pull/1908]

> Unauthorized topics are returned to the user
> --------------------------------------------
>
>                 Key: KAFKA-3396
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3396
>             Project: Kafka
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 0.9.0.0, 0.10.0.0
>            Reporter: Grant Henke
>            Assignee: Edoardo Comar
>            Priority: Critical
>             Fix For: 0.10.1.0
>
>
> Kafka's clients and protocol exposes unauthorized topics to the end user. This is often considered a security hole. To some, the topic name is considered sensitive information. Those that do not consider the name sensitive, still consider it more information that allows a user to try and circumvent security.  Instead, if a user does not have access to the topic, the servers should act as if the topic does not exist. 
> To solve this some of the changes could include:
>       - The broker should not return a TOPIC_AUTHORIZATION(29) error for requests (metadata, produce, fetch, etc) that include a topic that the user does not have DESCRIBE access to.
>       - A user should not receive a TopicAuthorizationException when they do not have DESCRIBE access to a topic or the cluster.
>      - The client should not maintain and expose a list of unauthorized topics in org.apache.kafka.common.Cluster. 
> Other changes may be required that are not listed here. Further analysis is needed. 



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