1.4. Creating Service Principals and Keytab Files for HDP

Each service in HDP must have its own principal. As services do not login with a password to acquire their tickets, their principal's authentication credentials are stored in a keytab file, which is extracted from the Kerberos database and stored locally with the service principal. 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.

Step 1: 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 is to provide a unique principal name for services that run on multiple hosts, like DataNodes and TaskTrackers. 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.

In general the $principal name part of the name should match the values in the table below. It is possible to use different names (except you must use HTTP) but this requires customizing many of the steps below. Note that the NameNode, Secondary NameNode, and Oozie require two principals each:

 

Table 13.1. Service Principal Names

Service NameDefault Principal Name

NameNode

nn and HTTP

Secondary NameNode

nn and HTTP

JobTracker

jt

TaskTracker

tt

DataNode

dn

HBase Master

hm

HBase RegionServer

rs

Hive Metastore/HiveServer2

hive

Oozie

oozie and HTTP

WebHCat

HTTP


For example: To create the principal for a DataNode service, issue this command:

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

Step 2: Extract the related keytab file and place it in the keytab directory (by default /etc/krb5.keytab) of the appropriate respective components:

kadmin:  xst -norandkey -k $keytab_file_name/fully.qualified.domain.name
[Important]Important

The Service Keytab filenames must match the principal name whose information they contain. HTTP must use the spnego filename.

If you use the default names, these names would be as follows:

 

Table 13.2. Service Keytab File Names

Service NameDefault Keytab File Name

NameNode

nn.service.keytab

AND

spnego.service.keytab

Secondary NameNode

nn.service.keytab

AND

spnego.service.keytab

JobTracker

jt.service.keytab

TaskTracker

tt.service.keytab

DataNode

dn.service.keytab

HBase Master

hm.service.keytab

HBase RegionServer

rs.service.keytab

Hive Metastore/HiveServer2

hive.service.keytab

Oozie

oozie.service.keytab

AND

spnego.service.keytab

WebHCat

spnego.service.keytab


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

kadmin: xst -k nn.service.keytab nn/$namenode-host   
kadmin: xst -k spnego.service.keytab HTTP/$namenode-host  

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

Step 3: Verify 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.

Step 4: Make the keytab files readable for other users:

 chmod -R 644 /etc/security/keytabs/*.keytab  

Do this on each respective service in your cluster.


loading table of contents...