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/$service-host-FQDN@$hadoop.realm

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

where

[Note]Note

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.

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

[Note]Note

The NameNode, Secondary NameNode, and Oozie require two principals each.

[Note]Note

If you are configuring High Availability (HA) for a Quorom-based NameNode, you must also generate a principle (jn/$FQDN) and keytab (jn.service.keytab) for each JournalNode. JournalNode also requires the keytab for its HTTP service. If the JournalNode is deployed on the same host as a NameNode, the same keytab file (spnego.service.keytab) can be used for both. In addition, HA requires two NameNodes. Both the active and standby NameNode require their own principle and keytab files. The service principles of the two NameNodes can share the same name, specified with the dfs.namenode.kerberos.principal property in hdfs-site.xml, but the NameNodes still have different fully qualified domain names.

 

Table 2.1. Service Principals

ServiceComponentMandatory Principal Name

HDFS

NameNode

nn/$FQDN

HDFS

NameNode HTTP

HTTP/$FQDN

HDFSSecondaryNameNodenn/$FQDN
HDFSSecondaryNameNode HTTPHTTP/$FQDN

HDFS

DataNode

dn/$FQDN

MR2History Serverjhs/$FQDN
MR2History Server HTTPHTTP/$FQDN
YARNResourceManagerrm/$FQDN
YARNNodeManagernm/$FQDN

Oozie

Oozie Server

oozie/$FQDN

Oozie

Oozie HTTP

HTTP/$FQDN

Hive

Hive Metastore

HiveServer2

hive/$FQDN

HiveWebHCat

HTTP/$FQDN

HBase

MasterServer

hbase/$FQDN

HBase

RegionServer

hbase/$FQDN

HueHue Interfacehue/$FQDN

ZooKeeper

ZooKeeper

zookeeper/$FQDN

Nagios ServerNagiosnagios/$FQDN
JournalNode Server[a]JournalNodejn/$FQDN
GatewayKnoxknox/$FQDN

[a] Only required if you are setting up NameNode HA.


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

kadmin: addprinc -randkey dn/$datanode-host@$hadoop.realm

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 -k $keytab_file_name $principal_name/fully.qualified.domain.name

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

 

Table 2.2. Service Keytab File Names

ComponentPrincipal NameMandatory Keytab File Name

NameNode

nn/$FQDNnn.service.keytab
NameNode HTTPHTTP/$FQDNspnego.service.keytab

SecondaryNameNode

nn/$FQDN nn.service.keytab
SecondaryNameNode HTTPHTTP/$FQDNspnego.service.keytab
DataNodedn/$FQDNdn.service.keytab
MR2 History Serverjhs/$FQDNnm.service.keytab
MR2 History Server HTTPHTTP/$FQDNspnego.service.keytab
YARNrm/$FQDN

rm.service.keytab

YARNnm/$FQDN

nm.service.keytab

Oozie Serveroozie/$FQDNoozie.service.keytab
Oozie HTTPHTTP/$FQDNspnego.service.keytab

Hive Metastore

HiveServer2

hive/$FQDN

hive.service.keytab

WebHCatHTTP/$FQDNspnego.service.keytab

HBase Master Server

hbase/$FQDN

hbase.service.keytab

HBase RegionServer

hbase/$FQDN

hbase.service.keytab

Huehue/$FQDNhue.service.keytab

ZooKeeper

zookeeper/$FQDN

zk.service.keytab

Nagios Servernagios/$FQDNnagios.service.keytab
Journal Server[a]jn/$FQDNjn.service.keytab
Knox Gateway[b]knox/$FQDNknox.service.keytab

[a] Only required if you are setting up NameNode HA.

[b] Only required if you are using a Knox Gateway.


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.


loading table of contents...