Jason Gustafson created KAFKA-12394:
---------------------------------------
Summary: 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
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)
