[
https://issues.apache.org/jira/browse/HDFS-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480142#comment-13480142
]
Ahad Rana commented on HDFS-4081:
---------------------------------
Hi Owen,
We discovered this problem because in our network the nodes set their
hostname to be a short name, and DNS returns the fully qualified host name
(i.e n01 and n01.region.prod.somecompany.com). The inconsistency arises
because in some cases the NN code uses the Java getHostName call to
retrieve the NN's hostname (returns n01) to form a principal name while
clients connecting to the NN use the Java getCanonicalName call (returns
n01.region....) to form principal names. We tried to address this issue by
explicitly setting the NN's principal via *dfs.namenode.kerberos.principal.
*
Unfortunately, the key *dfs.namenode.kerberos.principal *has different
meanings depending on the context in which it is used. In one case, the
Namenode uses it to establish the principal its server principal name. In
the other case, the same Namenode uses the same key to figure the principal
name to use with an incoming (client) connection. I believe the Hadoop
Security docs I have seen recommend that you create a unique (host
qualified) principal per machine (at least the CDH docs recommend this).
So, in this scenario you have different principal names for the NN and the
2NN (as an example). If someone uses the *dfs.namenode.kerberos.principal *key
to set an explicit principal name for the NN, authentication with the 2NN
breaks because the code in ServiceAuthorizationManager is unable to
construct a proper principal name for the 2NN from the explicit name set
for the NN.
Perhaps the short term fix is to better document how to use the *
dfs.namenode.kerberos.principal* config key. If you set its value to be an
explicit principal name, then you have to use the exact same principal name
across all nodes that try to authenticate with the secured NN protocol. If
you are using host qualified principal names for each node in the cluster,
then you must specify a pattern based principal name in
*dfs.namenode.kerberos.principal
*that can be used by the NN to both establish its own principal name and an
incoming client's principal name.
We worked around the issue by changing our NN / 2NN hostnames to match the
fully qualified names returned by DNS. Longer term, I would recommend that
we (a) fix the code in the NN to consistently use getCanonicalName whenever
it tries to use a hostname for the purposes of forming a principal name and
(b) perhaps split *dfs.namenode.kerberos.principal *into *
dfs.namenode.kerberos.principal* and *
dfs.namenode.kerberos.client.principal. *
I apologize for the lengthy answer :-)
Ahad.
> NamenodeProtocol and other Secure Protocols should use different config keys
> for serverPrincipal and clientPrincipal KerberosInfo components
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-4081
> URL: https://issues.apache.org/jira/browse/HDFS-4081
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: security
> Affects Versions: 2.0.0-alpha, 2.0.1-alpha, 2.0.2-alpha, 2.0.3-alpha
> Reporter: Ahad Rana
>
> The Namenode protocol (NamenodeProtocol.java) defines the same config key,
> dfs.namenode.kerberos.principal, for both ServerPrincipal and ClientPrincipal
> components of the KerberosInfo data structure. This overloads the meaning of
> the dfs.namenode.kerberos.principal config key. This key can be used to
> define the namenode's principal during startup, but in the client case, it is
> used by ServiceAuthorizationManager.authorize to create a principal name
> given an incoming client's ip address. If you explicitly set the principal
> name for the namenode in the Config using this key, it then breaks
> ServiceAuthorizationManager.authorize, because it expects this same value to
> contain a Kerberos principal name pattern NOT an explicit name.
> The solve this issue, the ServerPrincipal and ClientPrincipal components of
> the NamenodeProtocol should each be assigned unique Config keys.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
