Le 12 déc. 2014 à 03:13, Vinod Kumar Vavilapalli <[email protected]> a écrit :
> Auth to local mappings > - nn/[email protected] -> 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/[email protected]. 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/[email protected]) 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
