hadoop-common-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Toebbicke <...@pclella.cern.ch>
Subject Re: adding node(s) to Hadoop cluster
Date Fri, 12 Dec 2014 09:51:53 GMT

Le 12 déc. 2014 à 03:13, Vinod Kumar Vavilapalli <vinodkv@hortonworks.com> a écrit
:

> Auth to local mappings
> - nn/nn-host@cluster.com -> hdfs
> - dn/.*@cluster.com -> hdfs
> 
> The combination of the above lets you block any other user other than hdfs from faking
like a datanode.
> 
> Purposes
> - _HOST: Let you deploy all datanodes with the same principal value in all their configs.
> - Auth-to-local-mapping: Map kerberos principals to unix-login names to close the loop
on identity
> 
> Don't think your example of "somebody on an untrusted client can disguise as hdfs/nodename@REALM"
is possible at all with Kerberos. Any references to such possibilities? If it were possible,
all security is toast anyways, no?
> 

It's not yet toast, the term "untrusted" is a bit harsh as the "attacker" needs, of course,
a keytab entry for  dn/xxx.cluster.com@CLUSTER.COM.

However, take the example of several clusters in an organization of a size such that principal
creation is somewhat automated.

With the auth_to_local pattern "dn/.*@CLUSTER.COM -> hdfs" you give administrators of cluster1
(who can read the keytab of dn/cluster1node.cluster.com@CLUSTER.COM) the possibility to act
as hdfs on cluster2 through hdfs://cluster2.cluster.com/..., not something that is always
appropriate.

Now, I am aware that naming nodes in a cluster-specific way solves this, as you could form
a pattern. But believe it or not, here host names are derived from the purchase contract number.

I am also aware that using a cluster-specific prefix such as "cluster2-dn/" instead of the
constant prefix "dn/", provided that, by policy (!), for nodes in cluster1 principals of the
form "cluster2-dn/..." are never created.

Two possibilities which I don't have at hand.

But I was wondering how other people address this. At the same time hint that if there were
a -refreshAuthToLocal (and while we're writing the wishlist, a -refreshTopology), I could
continue to control access by auth_to_local which is comparatively painless.

And still... I may have misunderstood something and make a fuzz for nothing.

Thanks for your thoughts, 
Rainer


Mime
View raw message