[
https://issues.apache.org/jira/browse/KUDU-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126479#comment-16126479
]
Todd Lipcon commented on KUDU-2096:
-----------------------------------
A few notes:
- the C++ client (at least in Kudu 1.4 and earlier) always resolves the passed
host name into an IP and passes that into the SASL and krb5 libraries. We then
rely on 'rdns = true' setting (the default) in krb5.conf to resolve it back to
the canonical name of the host. So, if there is a DNS configuration like:
{code}
kudumaster.example.com CNAME server1.example.com
server1.example.com A 1.2.3.4
4.3.2.1.in-addr.arpa. PTR server1.example.com
{code}
then the C++ client will resolve 'kudumaster.example.com' to '1.2.3.4', and
then krb5 will reverse it to 'server1.example.com', the FQDN of the actual
host. The server already assumes and requires that its keytab have a principal
kudu/FQDN@REALM, so the incoming client's expected principal will match the
actual principal used by the server.
The Java client on the other hand seems to skip the canonicalization and will
try to find a principal kudu/kudumaster.example.com and fail, since the correct
principal is kudu/server1.example.com.
> 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)
