Todd Lipcon has submitted this change and it was merged. Change subject: java: fix ability to connect to a real Kerberized cluster ......................................................................
java: fix ability to connect to a real Kerberized cluster This fixes a couple issues seen when I tried to run the Java client from within Impala against a Kerberized Kudu cluster: * Previously, the ServerInfo class remembered the already-resolved address of the server rather than its hostname. This meant that we would try to connect to a Kerberos principal "kudu/1.2.3.4" rather than "kudu/foo.example.com". This typically would not match the actual principal the server was using, resulting in an error that the server principal was not found in the database. * We previously were using 'subject.doAs()' when initializing the SASL server, but not when evaluating challenges. It turns out that the GSSAPI mechanism only looks for the Kerberos credentials while evaluating the challenge. This moves the 'doAs()' to wrap the challenge. * Another issue with the SASL setup was that we were passing all of the available client mechanisms into Sasl.createSaslClient() before seeing which mechanisms the server was advertised. the SASL library seems to always prefer GSSAPI over PLAIN when available. This meant that, if the server had Kerberos credentials, it would attempt to use GSSAPI and not PLAIN even if connecting to a server which only advertised plain. This fixes the negotiation to no longer ignore the server-side advertised mechanisms, and instead actually negotiate by picking the best mechanism which is both advertised by the server and initializable by the client. * We previously assumed that Kerberos credentials would be available from the 'Subject' without any explicit login call. This isn't the case: we have to explicitly set up a LoginContext and Configuration to log in from the credentials cache. This changes the client constructor to login from the ccache if there is no Subject available with Kerberos credentials. With these changes I was able to run an Impala query against a cluster with -server_require_kerberos. Change-Id: I6b96fad3cfb40500d7a75e5070ea21bc8e00cbd8 Reviewed-on: http://gerrit.cloudera.org:8080/5922 Reviewed-by: Dan Burkert <danburk...@apache.org> Reviewed-by: Jean-Daniel Cryans <jdcry...@apache.org> Tested-by: Todd Lipcon <t...@apache.org> --- M java/kudu-client/src/main/java/org/apache/kudu/client/AsyncKuduClient.java M java/kudu-client/src/main/java/org/apache/kudu/client/ConnectionCache.java M java/kudu-client/src/main/java/org/apache/kudu/client/SecureRpcHelper.java M java/kudu-client/src/main/java/org/apache/kudu/client/ServerInfo.java A java/kudu-client/src/main/java/org/apache/kudu/util/SecurityUtil.java M java/kudu-client/src/test/java/org/apache/kudu/client/MiniKdc.java M java/kudu-client/src/test/java/org/apache/kudu/client/MiniKuduCluster.java M java/kudu-client/src/test/java/org/apache/kudu/client/TestConnectionCache.java M java/kudu-client/src/test/java/org/apache/kudu/client/TestMiniKdc.java M java/kudu-client/src/test/java/org/apache/kudu/client/TestMiniKuduCluster.java M java/kudu-client/src/test/java/org/apache/kudu/client/TestRemoteTablet.java 11 files changed, 284 insertions(+), 128 deletions(-) Approvals: Dan Burkert: Looks good to me, approved Jean-Daniel Cryans: Looks good to me, approved Todd Lipcon: Verified -- To view, visit http://gerrit.cloudera.org:8080/5922 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: merged Gerrit-Change-Id: I6b96fad3cfb40500d7a75e5070ea21bc8e00cbd8 Gerrit-PatchSet: 5 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Todd Lipcon <t...@apache.org> Gerrit-Reviewer: Dan Burkert <danburk...@apache.org> Gerrit-Reviewer: Jean-Daniel Cryans <jdcry...@apache.org> Gerrit-Reviewer: Todd Lipcon <t...@apache.org>
