Our Community is getting an upgrade! To get everything ready for the relaunch, we’ll be placing the site in read-only mode starting September 21st.
We really appreciate your understanding while we get things set up behind the scenes. Catch up on all the exciting details about the move here.
Need help or have questions? Drop us a line at [email protected]
Created on 05-11-2018 04:55 AM - edited 09-16-2022 01:43 AM
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
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/[email protected] with password. kadmin.local: addprinc [email protected] WARNING: no policy specified for [email protected]; defaulting to no policy Enter password for principal "[email protected]": Re-enter password for principal "[email protected]": Principal "[email protected]" created.
Do the above step for all the new users
addprinc [email protected] addprinc [email protected] addprinc [email protected] addprinc [email protected]
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 [email protected] -k 1 -e RC4-HMAC Password for [email protected]: 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 [email protected]
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 [email protected] .... .................. .............. 1 05/10/18 01:00:50 [email protected]
Test the new user1 should try grabbing a Kerberos ticket (keytab + principal)
# kinit -kt /etc/security/keytabs/user1.keytab [email protected]
The below command should show the validity of the Kerberos ticket
# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: [email protected] Valid starting Expires Service principal 05/10/2018 10:53:48 05/11/2018 10:53:48 krbtgt/[email protected]
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