Repository navigation
Conversation
Callers that must talk to servers with certificates outside the default trust store can opt out explicitly with KyuubiRestClient.Builder.insecureSsl(true).
|
Thanks for the fix! I tested 35 scenarios against Kyuubi 1.12.0, 1.11.1, and 1.10.3 on our Kubernetes cluster, each with Java 8 and 17, plus CLI upgrade checks. These covered TLS validation, LDAP/SPNEGO, client recreation/failover, SQL, and Spark batch jobs. Everything behaved as expected, and I didn’t find any new correctness issues. Could we also add a short migration note for the new TLS defaults? Existing HTTPS connections with untrusted certificates or hostname mismatches will now fail. Java callers can configure a JVM truststore or opt out with insecureSsl(true). For kyuubi-ctl, which has no insecure option, users can pass javax.net.ssl.trustStore, javax.net.ssl.trustStoreType, and javax.net.ssl.trustStorePassword through KYUUBI_CTL_JAVA_OPTS. Hostname mismatches still need a matching URL or certificate, even after importing the certificate. This would help users upgrade without surprises. |
|
Thank you for your review. Added migration note @wangzhigang1999 |
Why are the changes needed?
Enable TLS cert verification in Kyuubi REST client. If user wants to disable it, set
KyuubiRestClient.Builder.insecureSsl(true).How was this patch tested?
Added test cases
Was this patch assisted by generative AI tooling?
Assisted-by: OpenCode (MiniMax-M3.1-Flash)