THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Improve diagnostics for SASL authentication failures.
- Reduce retries when authentication fails. Authentication failures should be treated as non-retriable exceptions rather than transient failures.
- Reduce blocking in clients when authentication fails. If connections to all brokers fail connection to a broker fails authentication, metadata wait operations in producers and consumers should avoid unnecessary blocking and throw an exception indicating authentication failure.
...
ApiVersionsrequest is sent by the client to determineSaslHandshakeversion prior to authentication. This is supported by 0.10.x brokers, retaining compatibility between 0.11.x clients and 0.10.x brokers. Since 0.10.x brokers treat schema exceptions in the first request as GSSAPI auth message for compatibility with 0.9.x clients,ApiVersionsv0request will be used. As no throttling is performed prior to authentication,v0is sufficient for the initial request.- If
SaslHandshakeversion isv0, then the older wire format is used for authentication. SASL authentication messages are sent as length-encoded byte arrays without wrapping the messages with Kafka protocol headers. - If
SaslHandshakeversion isv1, clients will send SASL authentication messages using the newSaslAuthenticaterequest/response format, where the actual SASL authentication message blobs are wrapped in the Kafka protocol. The network layer code for SASL already does creation and parsing of Kafka protocol requests and responses to processSaslHandshakerequest, so this will be a straightforward change. - The final message from the broker will indicate if authentication succeeded or failed. Successful authentications will be logged at debug level. Failed authentications will be logged as warnings.
Authentication error handling
- If authentication fails, broker will return an error response and then close the connection.
- Java clients will log a warning for authentication failures, distinguishing these from EOF exceptions due to connection failure.
- Nodes to which connection failed due to authentication failure will be blacked out , no more attempts will be made to connect to these nodes. The blackout will be cleared if authentication with another broker is successful to re-enable connections after for the reconnect backoff interval to handle timing issues when credentials are updated.
- Producer
waitForMetadataand consumerensureCoordinatorReadywill be updated to throwAuthenticationFailedExceptionif connections to all available brokers fail authentication. Blackout on all nodes will be cleared before throwing the exception so that explicit retries by the client can reconnect after the reconnect backoff interval. This is to handle the case where client was started before credentials were created.connection to a broker fails authentication.
Compatibility, Deprecation, and Migration Plan
...
Most of the fields in the headers like client-id are irrelevant for SASL messages which are treated as a blob by Kafka. Hence it may be unnecessary to add the entire header. Just a status/error code would be sufficient. Kafka request format was chosen since we already use this format for SaslHandshake requests, so the authenticators have knowledge of Kafka requests. Also, this enables the API to evolve in future if required.
Try all brokers before throwing AuthenticationException in clients to handle the case where credentials are being updated
It will be difficult to handle the case where credentials are different on brokers during an update since connection to one broker to obtain metadata may succeed while the subsequent produce to another broker could fail. It may be possible to improve the behaviour in future within the authentication handler by refreshing credentials when authentication fails. For now, authentication exception will be thrown on first failure so that misconfigured applications fail fast.