Blocker Description
Due to changes made here: https://github.com/apache/kafka/pull/12828
Connect now unconditionally loads SSL configs from the worker into rest clients it uses for cross-worker communication and uses them even when issuing requests to HTTP (i.e., non-HTTPS) URLs. Previously, it would only attempt to load (and validate) SSL properties when issuing requests to HTTPS URLs. This can cause issues when a Connect cluster has stopped securing its REST API with SSL but its worker configs still contain the old (and now-invalid) SSL properties. When this happens, REST requests that hit a follower worker but need to be forwarded to the leader will fail, and connectors that perform dynamic reconfigurations via ConnectorContext::requestTaskReconfiguration will fail to trigger that reconfiguration if they are not running on the leader.
In our testing environments - older versions without the linked changes pass with the following configuration, and newer versions with the changes fail:
ssl.keystore.location = /mnt/security/test.keystore.jks
ssl.keystore.password = [hidden]
ssl.keystore.type = JKS
ssl.protocol = TLSv1.2
It's important to note that the file /mnt/security/test.keystore.jks isn't generated for our non-SSL tests, however these configs are still included in our worker config file.
This leads to a 500 response when hitting the create connector REST endpoint with the following error:
{ "error_code":500, "message":"Failed to start RestClient: /mnt/security/test.keystore.jks is not a valid keystore" }
Attachments
Issue Links
- is caused by
-
KAFKA-14346 Remove static methods from internal Connect APIs for easier testing
-
- Resolved
-
- links to