Status

Current state: Under Discussion

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA: KAFKA-7975

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

We still have some users using very old Kafka client libraries, such as Kafka 8 and Kafka 9. We need a mechanism to force users to upgrade their client libraries, or forbid outdated client libraries.

Some old libraries are still supported by the new brokers, but can cause problems when we starting using some new features. Some examples are:

1. Kafka 8 consumer hangs when the message contains message header
2. LZ4 is not correctly handled in Kafka 8 and Kafka 9
3. Performance penalty of converting message format from V3 to V1 or V2 for the old consumers (KIP-31 - Move to relative offsets in compressed message sets) 

In general, we think it's reasonable to give cluster administrator the capability to forbid some client library version.

In this KIP, we propose to provide client API version to authorizer. So that, the user defined authorizer can decide allowing or not allowing the operation based on client library versions.

Public Interfaces

A public interface is any change to the following:

• Binary log format

  No

• The network protocol and api behavior

  No

• Any class in the public packages under clientsConfiguration, especially client configuration

  No

• Monitoring

  No

• Command line tools and arguments

  No

• Anything else that will likely break existing users in some way when they upgrade
  No

Proposed Changes

Public Interfaces and classes

Authorizer

package kafka.security.auth

/** ...
 *  ...
 */
trait Authorizer {
  /** ...
   *  ...
   */
  
  /**
   * @param session The session being authenticated.
   * @param operation Type of operation client is trying to perform on resource.
   * @param resource Resource the client is trying to access.
+  * @param apiVersion The client API version of the request.
   * @return
   */
-  def authorize(session: Session, operation: Operation, resource: Resource): Boolean
+  def authorize(session: Session, operation: Operation, resource: Resource, apiVersion: Short): Boolean
}

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?
  No impact to the users that are not using user-defined authorizer. For the users that are using user-defined authorizer, they will have to modify their authorizer code to use the new interface.

Rejected Alternatives

Alternative 1 - Add a new broker configuration (e.g. min_api_version)

The method proposed in this KIP provides more flexibility to the cluster administrators. For example, they can forbid old consumers, but still allow old producers; or forbid old clients for a set of topics (e.g. the topics that are using new message format), while still allow for the other topics.

Alternative 2 - Provide the authorizer the entire Request object

From the request object, users can many other information about the request (e.g. the message content for produce request), in addition to the api version. The concern is may expose too much broker internal details to the authorizer, and may be abused.