[
https://issues.apache.org/jira/browse/KUDU-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129459#comment-16129459
]
Attila Bukor commented on KUDU-2096:
------------------------------------
So we're storing each master address as a Guava
{{com.google.common.net.HostAndPort}} which stores it internally as a String.
This is then passed to {{com.sun.security.sasl.gsskerb.GssKrb5Client}}
unmodified currently which also doesn't try to resolve it or canonicalize it no
matter what's configured in /etc/krb5.conf if I'm reading it correctly and I
assume this is the problem.
So another problem is I couldn't find a way to mimic the canon == true && rdns
== false way (at least not without some DNS library) as from the String we need
to create an {{InetAddress}} by calling {{InetAddress.getByName(String host)}}
which would result in reverse resolution by default. After this we can call
{{InetAddress.getCanonicalHostName()}} on it depending if
{{canonicalize_host_name}} is set true. In case it's false we can skip this
whole thing and return the original String. This way we can still control this
behavior with the {{canonicalize_host_name}} flag, but the default is also
sensible, the only thing we can't do is basically the one that doesn't really
make sense.
Do you think this is a good approach? Should I open a bug/improvement JIRA for
this or should I just reference this one in the commit? I have a working
proof-of-concept, I need to make it configurable based on your decision and
some tests.
> 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)
