This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state: Draft Adopted

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

...

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

co-authored-by: Edoardo Comar ecomar@uk.ibm.com

Motivation

Currently when building a Principal, the builder has access to the an AuthenticationContext which contains the security protocol as well as the client address. However since 0.10.2.0 Kafka can have multiple listeners for the same security protocol . It would be beneficial to also have access to the listener name in the AuthenticationContext to properly identify the connection.
For example with the following configuration, it's not currently possible in a custom PrincipalBuilder to identify if a connection is from an internal or external network as both have the same security protocol:

...

using listener names (listener.security.protocol.map). While we can identify the source of the connection using the client address, having the listener name would make it simpler as IPs/networks can change and it currently requires to parse the client IP.

Public Interfaces

A new public method will be added to AuthenticationContext:

/**
 * Name of the listener used for the connection
 */
ListenerNameString listenerName();

As well as to all the existing implementations: PlaintextAuthenticationContext, SslAuthenticationContext and SaslAuthenticationContext

Proposed Changes

...

.

That will return the String value (value()) of the ListenerName used by the connection. For example, with the following configuration:

listener.security.protocol.map=CLIENT:SASL_PLAINTEXT,REPLICATION:PLAINTEXT,INTERNAL_SASL:SASL_PLAINTEXT
advertised.listeners=CLIENT://cluster1.foo.com:9092,REPLICATION://broker1.replication.local:9093,INTERNAL_SASL://broker1.local:9094
listeners=CLIENT://192.1.1.8:9092,REPLICATION://10.1.1.5:9093,INTERNAL_SASL://10.1.1.5:9094


For a client connecting to:

• 192.1.1.8:9092, it will return "CLIENT"
• 10.1.1.5:9093, it will return "REPLICATION"
• 10.1.1.5:9094, it will return "INTERNAL_SASL"

Compatibility, Deprecation, and Migration Plan

...

No compatibility, deprecation, migration plan required.

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.

...