[
https://issues.apache.org/jira/browse/KUDU-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129733#comment-16129733
]
Todd Lipcon commented on KUDU-2096:
-----------------------------------
I see your point that it is probably not possible to duplicate the 'canon =
true & rdns = false' configuration in Java. That's a shame since it means that
C++ and Java clients may act different on those systems.
I spent some time looking at the Hadoop RPC code, since I figure that many
people installing Kudu (particularly with the Java client) probably already
have working systems with Hadoop's Kerberos usage. It seems it is quite
configurable, but more or less does something like:
- the server actually advertises its own principal based on what it thinks its
FQDN is, during RPC negotiation, before the SASL negotiation starts
- the client then validates it using a couple rules:
-- the user may specify a regex pattern of what is allowed ( see HADOOP-9789 ).
This isn't often used as far as I know.
-- if there is no regex, and assuming no other exotic configs set up (there is
a 'use_ip' config which disables any canonicalization if the user specifies an
IP), it ends up calling to InetAddress.getCanonicalHostName (in
SecurityUtil#getServerPrincipal(String, InetAddress)
We've generally required that Kudu clusters have sane DNS where every host has
a canonical name and IP which have correct forward and reverse lookups. So I
think probably the best option here is to just change the Java client to always
use getCanonicalHostName() rather than listening to whatever host is specified
by the user. If we need to add some complicated configurations later we can
consider it, but I think this should suffice for 99% of correctly-set-up
clusters even if it doesn't perfectly respect krb5.conf.
> Document necessary configuration for Kerberos with master CNAMEs
> ----------------------------------------------------------------
>
> Key: KUDU-2096
> URL: https://issues.apache.org/jira/browse/KUDU-2096
> Project: Kudu
> Issue Type: Task
> Components: documentation, security
> Reporter: Todd Lipcon
>
> Currently our docs recommend using CNAMEs for master addresses to simplify
> moving them around. However, if clients connect to a master with its
> non-canonical name, there are some complications with Kerberos principals,
> etc. We should test and document the necessary steps for such a configuration.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
