DocsHortonworks Data Platform

 

 1.5. Creating Hadoop Service Principals and Keytabs

Each service in HDP must have its own principal. A principal name in a given realm is comprised of the primary and an instance (for example, primary/instance@REALM). Because services do not login with a password to acquire Kerberos tickets, the principal authentication key is stored in a keytab file. This keytab file is generated from the Kerberos database and stored locally on the service component host.

First you must create the principal, using mandatory naming conventions. Then you must create the keytab file with that principal's information and copy the file to the keytab directory on the appropriate service host.

[Note]Note

Principals can be created either on the KDC machine itself or through the network, using a previously created “admin” principal. The following instructions assume you are using the KDC machine and using the kadmin.local command line administration utility. Using kadmin.local on the KDC machine allows you to create principals without needing to create a separate "admin" principal before you start.

  1. Open the kadmin.local utility on the KDC machine

    /usr/sbin/kadmin.local

  2. Create a service principal using the kadmin utility:

    kadmin: addprinc -randkey $principal_name/$fully.qualified.domain.name@YOUR-REALM.COM

    You must have a principal with administrative permissions to use this command. The randkey is used to generate the password.

    Note that in the example each service principal's name has appended to it the fully qualified domain name of the host on which it is running. This ensures that each service has a unique principal name.

    The addition of the hostname serves to distinguish, for example, a request from DataNode A from a request from DataNode B. This is important for two reasons:

    • If the Kerberos credentials for one DataNode are compromised, it does not automatically lead to all DataNodes being compromised

    • If multiple DataNodes have exactly the same principal and are simultaneously connecting to the NameNode, and if the Kerberos authenticator being sent happens to have same timestamp, then the authentication would be rejected as a replay request.

    The $principal_name part of the name must match the values in the table below:

    Note that the NameNode, Secondary NameNode, and Oozie require two principals each.

     

    Table 15.2. Service Principal Names

    Service NameComponentMandatory Principal Name

    HDFS

    NameNode

    nn/$FQDN

    HDFS

    NameNode HTTP

    HTTP/$FQDN

    HDFS

    Secondary NameNode

    nn/$FQDN

    HDFS

    Secondary NameNode HTTP

    HTTP/$FQDN

    HDFS

    DataNode

    dn/$FQDN

    MapReduce

    JobTracker

    jt/$FQDN

    MapReduce

    TaskTracker

    tt/$FQDN

    HBase

    MasterServer

    hbase/$FQDN

    HBase

    RegionServer

    hbase/$FQDN

    ZooKeeper

    ZooKeeper

    zookeeper/$FQDN

    Hive

    Hive Metastore HiveServer2

    hive/$FQDN

    Hive

    WebHCat

    HTTP/$FQDN

    Oozie

    Oozie Server

    oozie/$FQDN

    Oozie

    Oozie HTTP

    HTTP/$FQDN

    Hue hue

    For example: To create the principal for a DataNode service, execute the following command: 

    kadmin: addprinc -randkey dn/$DataNode_Host_FQDN@EXAMPLE.COM

  3. After the principals are created in the database, extract related keytab files for transfer to the appropriate host:

    • For RHEL/CentOS 5.x: 

      kadmin: xst -k $keytab_file_name $principal_name/fully.qualified.domain.name

    • For RHEL/CentOS 6.x: 

      kadmin: xst -norandkey -k $keytab_file_name $principal_name/fully.qualified.domain.name

    • For SLES: 

      kadmin: xst -norandkey -k $keytab_file_name $principal_name/fully.qualified.domain.name

    You must use the mandatory names for the $keytab_file_name variable as shown in this table.

     

    Table 15.3. Service Keytab File Names

    ComponentMandatory Principal NameMandatory Keytab File Name

    NameNode

    nn/$FQDN

    nn.service.keytab

    NameNode HTTP

    HTTP/$FQDN

    spnego.service.keytab

    Secondary NameNode

    nn/$FQDN

    nn.service.keytab

    Secondary NameNode HTTP

    HTTP/$FQDN

    spnego.service.keytab

    DataNode

    dn/$FQDN

    dn.service.keytab

    JobTracker

    jt/$FQDN

    jt.service.keytab

    TaskTracker

    tt/$FQDN

    tt.service.keytab

    HBase MasterServer

    hbase/$FQDN

    hbase.service.keytab

    HBase RegionServer

    hbase/$FQDN

    hbase.service.keytab

    ZooKeeper

    zookeeper/$FQDN

    zk.service.keytab

    Hive Metastore HiveServer2

    hive/$FQDN

    		hive.service.keytab

    WebHCat

    HTTP/$FQDN

    spnego.service.keytab

    Oozie Server

    oozie/$FQDN

    		oozie.service.keytab

    Oozie HTTP

    HTTP/$FQDN

    		spnego.service.keytab
    Huehuehue.service.keytab

    For example: To create the keytab files for the NameNode, issue these commands: 

     kadmin: xst -k nn.service.keytab nn/<$NameNode_Host_FQDN> 
kadmin: xst -k spnego.service.keytab HTTP/<$NameNode_Host_FQDN>

    When you have created the keytab files, copy them to the keytab directory of the respective service hosts.

  4. When the keytab files have been created, on each host create a directory for them and set appropriate permissions. 

    mkdir -p /etc/security/keytabs/
chown root:$HADOOP_GROUP /etc/security/keytabs
chmod 750 /etc/security/keytabs

    where $HADOOP_GROUP is a common group shared by services. For example, hadoop.

  5. Set appropriate permissions for the keytabs.

    1. On the NameNode and Secondary NameNode hosts, execute the following command:

      chown $HDFS_USER:$HADOOP_GROUP /etc/security/keytabs/nn.service.keytab
chmod 400 /etc/security/keytabs/nn.service.keytab
chown root:$HADOOP_GROUP /etc/security/keytabs/spnego.service.keytab
chmod 440 /etc/security/keytabs/spnego.service.keytab

      Execute the following command on all the slave nodes (DataNodes).

      chown $HDFS_USER:$HADOOP_GROUP /etc/security/keytabs/dn.service.keytab  
chmod 400 /etc/security/keytabs/*.service.keytab

    2. On JobTracker:

      chown $MAPRED_USER:$HADOOP_GROUP /etc/security/keytabs/jt.service.keytab 
chmod 400 /etc/security/keytabs/*.service.keytab

      On all the slave nodes (TaskTrackers).

      chown $MAPRED_USER:$HADOOP_GROUP /etc/security/keytabs/tt.service.keytab
chmod 400 /etc/security/keytabs/*.service.keytab

    3. On HBase MasterServer, RegionServers, and ZooKeeper hosts:

      chown $HBASE_USER:$HADOOP_GROUP /etc/security/keytabs/hbase.service.keytab 
chmod 400 /etc/security/keytabs/hbase.service.keytab
chown $ZOOKEEPER_USER:$HADOOP_GROUP /etc/security/keytabs/zk.service.keytab 
chmod 400 /etc/security/keytabs/zk.service.keytab

    4. On the host that runs the Hive Metastore, HiveServer2 and WebHCat:

      chown $HIVE_USER:$HADOOP_GROUP /etc/security/keytabs/hive.service.keytab 
chmod 400 /etc/security/keytabs/hive.service.keytab
chown root:$HADOOP_GROUP /etc/security/keytabs/spnego.service.keytab 
chmod 440 /etc/security/keytabs/spnego.service.keytab

    5. On the Oozie server:

      chown $OOZIE_USER:$HADOOP_GROUP /etc/security/keytabs/oozie.service.keytab 
chmod 400 /etc/security/keytabs/oozie.service.keytab
chown root:$HADOOP_GROUP /etc/security/keytabs/spnego.service.keytab
chmod 440 /etc/security/keytabs/spnego.service.keytab

    6. On the Hue server:

      chown hue:$HADOOP_GROUP /etc/security/hue.service.keytab
 chmod 600 /etc/security/hue.service.keytab

    where

    • $HDFS_USER is the user owning the HDFS services. For example, hdfs.

    • $MAPRED_USER is the user owning the MapRed services. For example, mapred.

    • $HBASE_USER is the user owning the HBase services. For example, hbase.

    • $ZOOKEEPER_USER is the user owning the ZooKeeper services. For example, zookeeper.

    • $HIVE_USER is the user owning the Hive services. For example, hive.

    • $OOZIE_USER is the user owning the Oozie services. For example, oozie.

    • $HADOOP_GROUP is a common group shared by services. For example, hadoop.

  6. Confirm that the correct keytab files and principals are associated with the correct service using the klist command. For example, on the NameNode:

    klist –k -t /etc/security/nn.service.keytab

    Do this on each respective service in your cluster.

Legal notices
loading table of contents...