[
https://issues.apache.org/jira/browse/KAFKA-12394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293235#comment-17293235
]
Jason Gustafson commented on KAFKA-12394:
-----------------------------------------
The specific case where this came up was `DeleteTopic` handling. It sounds like
there is basic agreement to use `TOPIC_AUTHORIZATION_FAILED`. Unless there are
objections, I will go ahead and merge this into the minor PR here:
https://github.com/apache/kafka/pull/10223.
> Consider topic id existence and authorization errors
> ----------------------------------------------------
>
> Key: KAFKA-12394
> URL: https://issues.apache.org/jira/browse/KAFKA-12394
> Project: Kafka
> Issue Type: Improvement
> Reporter: Jason Gustafson
> Priority: Major
>
> We have historically had logic in the api layer to avoid leaking the
> existence or non-existence of topics to clients which are not authorized to
> describe them. The way we have done this is to always authorize the topic
> name first before checking existence.
> Topic ids make this more difficult because the resource (ie the topic name)
> has to be derived. This means we have to check existence of the topic first.
> If the topic does not exist, then our hands are tied and we have to return
> UNKNOWN_TOPIC_ID. If the topic does exist, then we need to check if the
> client is authorized to describe it. The question comes then what we should
> do if the client is not authorized?
> The current behavior is to return UNKNOWN_TOPIC_ID. The downside is that this
> is misleading and forces the client to retry even though they are doomed to
> hit the same error. However, the client should generally handle this by
> requesting Metadata using the topic name that they are interested in, which
> would give them a chance to see the topic authorization error. Basically the
> fact that you need describe permission in the first place to discover the
> topic id makes this an unlikely scenario.
> There is an argument to be made for TOPIC_AUTHORIZATION_FAILED as well.
> Basically we could take the stance that we do not care about leaking the
> existence of topic IDs since they do not reveal anything about the underlying
> topic. Additionally, there is little likelihood of a user discovering a valid
> UUID by accident or even through brute force. The benefit of this is that
> users get a clear error for cases where a topic Id may have been discovered
> through some external means. For example, an administrator finds a topic ID
> in the logging and attempts to delete it using the new `deleteTopicsWithIds`
> Admin API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
