[
https://issues.apache.org/jira/browse/KAFKA-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280293#comment-15280293
]
Grant Henke commented on KAFKA-3396:
------------------------------------
[~ecomar] Thanks for working on a patch! Feel free to assign to yourself to
this jira and send a PR. I am sure the exact rules may require some discussion.
Can you help my understand why don't we want to return
UNKNOWN_TOPIC_OR_PARTITION when auto-create topic is on, but the user has no
CREATE permission on Cluster?
FYI: We are slowly woking on moving auto-creation to be client side
(KAFKA-2410), but that requires some of the
[KIP-4|https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations]
work first. I am hoping to get that work done shortly after the 0.10 release.
> Unauthorized topics are returned to the user
> --------------------------------------------
>
> Key: KAFKA-3396
> URL: https://issues.apache.org/jira/browse/KAFKA-3396
> Project: Kafka
> Issue Type: Bug
> Reporter: Grant Henke
>
> 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)
