Iy you have deployed and secured your multi-node-cluster with an MIT KDC running on a Linux box (dedicated or not), this can also be applied on a single node cluster. Below is a step by step procedure to grant a group of user(s) on the Edge node with access to services in the cluster. Assumption KDC is running KDC is created KDC user and a master password is available REALM: DEV.COM Users: user1 to user5 Edge node: for users Kerberos Admin user is root or sudoer A good solution security-wise is to copy the generated keytabs to that users' home directory. If these are local Unix users NOT Active directory then create the keytabs in e.g /tmp and later copy them to their respective home directories and make sure to change the correct permissions on the keytabs. A good practice is to ensure a node dedicated to users usually called an EDGE NODE all client software is installed here and not on the Data or Name Nodes! Change directory to tmp # cd /tmp If you have root access, no need for sudo, specify the password for user1 # sudo kadmin.local
Authenticating as principal root/admin@DEV.COM with password.
kadmin.local: addprinc user1@DEV.COM
WARNING: no policy specified for user1@DEV.COM; defaulting to no policy
Enter password for principal "user1@DEV.COM":
Re-enter password for principal "user1@DEV.COM":
Principal "user1@DEV.COM" created. Do the above step for all the new users addprinc user2@DEV.COM
addprinc user3@DEV.COM
addprinc user4@DEV.COM
addprinc user5@DEV.COM The keytabs with be generated in the current directory Generate keytab for user1 The keytab will be generated in the current directory # sudo ktutil
ktutil: addent -password -p user1@DEV.COM -k 1 -e RC4-HMAC
Password for user1@DEV.COM:
ktutil: wkt user1.keytab
ktutil: q You MUST repeat the above for all the 5 users Copy the newly created keytab to the user's home directory, in this example I have copied the keytab to /etc/security/keytabs # cp user1.keytab /etc/security/keytabs Change ownership & permission here user1 belongs to hadmin group # chown user1:hadmin user1.keytab Again do the above for all the other users. A good technical and security best practice is to copy the keytabs from the kdc to edge node respective home directories and change the ownership of the keytabs Validate the principals in this example the keytabs are in /etc/security/keytabs # klist -kt /etc/security/keytabs/user1.keytab
Keytab name: FILE:/etc/security/keytabs/user1.keytab
KVNO Timestamp Principal
----------- ------------------- ------------------------------------------------------
1 05/10/2018 10:46:27 user1@DEV.COM To ensure successful ticket attribution the newly created user should validate the principal. See example below and use it grab a ticket, the principal will be concatenated with the keytab when running the kinit # klist -kt /etc/security/keytabs/user1.keytab
Keytab name: FILE:/etc/security/keytabs/user1.keytab
KVNO Timestamp Principal
-------- ------------------------ --------------------------------------------------------
1 05/10/18 01:00:50 user1@DEV.COM
.... .................. ..............
1 05/10/18 01:00:50 user1@DEV.COM Test the new user1 should try grabbing a Kerberos ticket (keytab + principal) # kinit -kt /etc/security/keytabs/user1.keytab user1@DEV.COM The below command should show the validity of the Kerberos ticket # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user1@DEV.COM
Valid starting Expires Service principal
05/10/2018 10:53:48 05/11/2018 10:53:48 krbtgt/DEV.COM@DEV.COM You should be okay now access and successfully run jobs on the cluster see example Accessing Hive CLI with Kerberos ticket $ hive
2018-05-10 23:18:57 WARN [main] conf.HiveConf: HiveConf of name hive.custom-extensions.root does not exist
log4j:WARN No such property [maxFileSize] in org.apache.log4j.DailyRollingFileAppender.
Logging initialized using configuration in file:/etc/hive/2.6.2.0-205/0/hive-log4j.properties
hive> show databases;
OK
default
Time taken: 8.525 seconds, Fetched: 1 row(s) Success !! Accessing Hive without a Kerberos ticket¨ Destroy the Kerberos ticket $ kdestroy Validate the existence of absence of Kerberos ticket $ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1001) Accessing Hive CLI should fail
... View more
