question Best practices with Ranger security in Archives of Support Questions (Read Only)

Best practices with Ranger security

aliyesami — Thu, 08 Dec 2016 06:30:55 GMT

all the activities that I used to perform as hdfs should now be performed as which user since hdfs user is not in KDC by default ?

or do I have to add the hdfs user to KDC and then add it to the HIVE/HDFS plugins?

I tried using the dfsadmin command but its failing .

[root@hadoop1 ~]# sudo -u hdfs hdfs balancer -threshold 1
16/12/07 17:30:01 INFO balancer.Balancer: Using a threshold of 1.0
16/12/07 17:30:01 INFO balancer.Balancer: namenodes  = [hdfs://hadoop1.tolls.dot.state.fl.us:8020]
16/12/07 17:30:01 INFO balancer.Balancer: parameters = Balancer.BalancerParameters [BalancingPolicy.Node, threshold = 1.0, max idle iteration = 5, #excluded nodes = 0, #included nodes = 0, #source nodes = 0, #blockpools = 0, run during upgrade = false]
16/12/07 17:30:01 INFO balancer.Balancer: included nodes = []
16/12/07 17:30:01 INFO balancer.Balancer: excluded nodes = []
16/12/07 17:30:01 INFO balancer.Balancer: source nodes = []
Time Stamp               Iteration#  Bytes Already Moved  Bytes Left To Move  Bytes Being Moved
16/12/07 17:30:01 WARN ipc.Client: Exception encountered while connecting to the server :
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

Re: Best practices with Ranger security

slachterman — Thu, 08 Dec 2016 06:42:49 GMT

@Sami Ahmad you are receiving this error because you do not have a valid TGT for the hdfs user. You need to kinit with the keytab for the hdfs principal. You should be able to see the principal by running

klist -kte /etc/security/keytabs/hdfs.headless.keytab

This hdfs Kerberos principal was created when you kerberized the cluster. You can get a TGT from the KDC by running

kinit -kt /etc/security/keytabs/hdfs.headless.keytab <hdfs-principal>

You can run dfsadmin commands with any user that belongs to the dfs.permissions.supergroup group, it would be a better practice to run this using an admin principal that belonged to this group.

Re: Best practices with Ranger security

dvillarreal — Thu, 08 Dec 2016 07:25:56 GMT

Hi Sami,

Since the above command requires superuser privilege I would do it like this.

To your example,

[root@chupa1 ~]# sudo su - hdfs

hdfs@chupa1 ~]$ klist -kt /etc/security/keytabs/hdfs.headless.keytab 
Keytab name: FILE:/etc/security/keytabs/hdfs.headless.keytab
KVNO Timestamp         Principal
---- ----------------- --------------------------------------------------------
   3 12/05/16 17:05:04 hdfs-chupa@CHUPA.COM
   3 12/05/16 17:05:04 hdfs-chupa@CHUPA.COM
   3 12/05/16 17:05:04 hdfs-chupa@CHUPA.COM
   3 12/05/16 17:05:04 hdfs-chupa@CHUPA.COM
   3 12/05/16 17:05:04 hdfs-chupa@CHUPA.COM

[hdfs@chupa1 ~]$ kinit -kt /etc/security/keytabs/hdfs.headless.keytab hdfs-chupa@CHUPA.COM

[hdfs@chupa1 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_503
Default principal: hdfs-chupa@CHUPA.COM

Valid starting     Expires            Service principal
12/07/16 22:47:23  12/08/16 22:47:23  krbtgt/CHUPA.COM@CHUPA.COM
	renew until 12/07/16 22:47:23


hdfs@chupa1 ~]$ hdfs balancer -threshold 1
16/12/07 22:47:47 INFO balancer.Balancer: Using a threshold of 1.0
16/12/07 22:47:47 INFO balancer.Balancer: namenodes  = [hdfs://chupa1.openstacklocal:8020]
16/12/07 22:47:47 INFO balancer.Balancer: parameters = Balancer.BalancerParameters [BalancingPolicy.Node, threshold = 1.0, max idle iteration = 5, #excluded nodes = 0, #included nodes = 0, #source nodes = 0, #blockpools = 0, run during upgrade = false]
16/12/07 22:47:47 INFO balancer.Balancer: included nodes = []
16/12/07 22:47:47 INFO balancer.Balancer: excluded nodes = []
16/12/07 22:47:47 INFO balancer.Balancer: source nodes = []
Time Stamp               Iteration#  Bytes Already Moved  Bytes Left To Move  Bytes Being Moved
16/12/07 22:47:49 INFO balancer.KeyManager: Block token params received from NN: update interval=10hrs, 0sec, token lifetime=10hrs, 0sec
16/12/07 22:47:49 INFO block.BlockTokenSecretManager: Setting block keys
16/12/07 22:47:49 INFO balancer.KeyManager: Update block keys every 2hrs, 30mins, 0sec
16/12/07 22:47:50 INFO balancer.Balancer: dfs.balancer.movedWinWidth = 5400000 (default=5400000)
16/12/07 22:47:50 INFO balancer.Balancer: dfs.balancer.moverThreads = 1000 (default=1000)
16/12/07 22:47:50 INFO balancer.Balancer: dfs.balancer.dispatcherThreads = 200 (default=200)
16/12/07 22:47:50 INFO balancer.Balancer: dfs.datanode.balance.max.concurrent.moves = 5 (default=5)
16/12/07 22:47:50 INFO balancer.Balancer: dfs.balancer.getBlocks.size = 2147483648 (default=2147483648)
16/12/07 22:47:50 INFO balancer.Balancer: dfs.balancer.getBlocks.min-block-size = 10485760 (default=10485760)
16/12/07 22:47:50 INFO block.BlockTokenSecretManager: Setting block keys
16/12/07 22:47:50 INFO balancer.Balancer: dfs.balancer.max-size-to-move = 10737418240 (default=10737418240)
16/12/07 22:47:50 INFO balancer.Balancer: dfs.blocksize = 134217728 (default=134217728)
16/12/07 22:47:50 INFO net.NetworkTopology: Adding a new node: /default-rack/172.26.76.168:1019
16/12/07 22:47:50 INFO net.NetworkTopology: Adding a new node: /default-rack/172.26.76.166:1019
16/12/07 22:47:50 INFO net.NetworkTopology: Adding a new node: /default-rack/172.26.76.167:1019
16/12/07 22:47:50 INFO balancer.Balancer: 0 over-utilized: []
16/12/07 22:47:50 INFO balancer.Balancer: 0 underutilized: []
The cluster is balanced. Exiting...
Dec 7, 2016 10:47:50 PM           0                  0 B                 0 B                0 B
Dec 7, 2016 10:47:50 PM  Balancing took 3.202 seconds

Re: Best practices with Ranger security

aliyesami — Thu, 08 Dec 2016 10:56:13 GMT

yes that did the trick , but its a different command than I was using ,so how does this command works?

so far I am using "kinit <username>" to get tickets and when I do this it asks for a password but your command did not ask for a password , why ?

Re: Best practices with Ranger security

slachterman — Fri, 09 Dec 2016 02:27:15 GMT

@Sami Ahmad because this version of the command uses the keytab. With Keberos, access to the keytab file is equivalent to knowledge of the password. Please see https://web.mit.edu/kerberos/krb5-1.12/doc/basic/keytab_def.html

Please accept this answer if it was helpful in resolving your issue.