Creating a local hadoop principal and keytab in a Kerberized cluster

[#1]

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