[
https://issues.apache.org/jira/browse/KUDU-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17318002#comment-17318002
]
ASF subversion and git services commented on KUDU-1884:
-------------------------------------------------------
Commit d546588da6d90c72a8dfcb8256e2a898ab55e96d in kudu's branch
refs/heads/master from Attila Bukor
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=d546588 ]
KUDU-1884 Make Kerberos principal customizable
In a Kerberized cluster, all Kudu servers service principal names (SPN)
are, by default, set to "kudu/_HOST". While this is configurable on the
server side, the SASL protocol name was hard-coded to "kudu" on the
client-side, meaning that if the SPN was anything other than "kudu", the
clients weren't able to connect to the Kudu servers. The 'principal'
flag was tagged as unsafe and experimental for this reason.
This patch allows changing the SASL protocol name in the C++ client
using the KuduClientBuilder API and the CLI tools using a new
'--sasl_protocol_name' flag, and makes the servers use the configured
principal for the RPC.
Java and Python client support will be added in separate patches.
Change-Id: I0c5e55714b98affe7c7dd095ce6ee37cd6bd3ddd
Reviewed-on: http://gerrit.cloudera.org:8080/17279
Tested-by: Kudu Jenkins
Reviewed-by: Alexey Serbin <aser...@cloudera.com>
Reviewed-by: Grant Henke <granthe...@apache.org>
> Support customizing Kerberos principal
> --------------------------------------
>
> Key: KUDU-1884
> URL: https://issues.apache.org/jira/browse/KUDU-1884
> Project: Kudu
> Issue Type: Improvement
> Components: security
> Affects Versions: 1.3.0
> Reporter: Todd Lipcon
> Assignee: Attila Bukor
> Priority: Major
> Labels: config
>
> Currently (aiming for Kudu 1.3) the Kerberos principal is hardcoded to
> 'kudu/_HOST'. While we have a flag to change it on the server, it isn't
> effective because we have no way to configure it on clients.
> The difficulty here is that there is currently no concept of Kudu client
> configuration files, so while we could theoretically add a new API to
> KuduClientBuilder, this would then mean that everyone embedding the API would
> have to add a new configuration, etc. We should consider a more generic
> key/value "connection properties" (as used by JDBC URLs) or some concept of a
> client configuration file (with an API to specify where to find it, etc).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
