2.3. Adding Security Information to Configuration Files

To the core-site.xml file on every host in your cluster, you must add the following information:

The XML for these entries:

  <property>   
        <name>hadoop.security.authentication</name>   
        <value>kerberos</value>   
        <description>    Set the
        authentication for the cluster. Valid values are: simple or   
        kerberos.   
        </description>  
</property> 

<property>  
        <name>hadoop.security.authorization</name>  
        <value>true</value>  
        <description>      Enable
        authorization for different protocols.  
        </description> 
</property>    

<property>
    
        <name>hadoop.security.auth_to_local</name>    
        <value>        
        RULE:[2:$1@$0]([jt]t@.*EXAMPLE.COM)s/.*/mapred/        
        RULE:[2:$1@$0]([nd]n@.*EXAMPLE.COM)s/.*/hdfs/        
        RULE:[2:$1@$0](hm@.*EXAMPLE.COM)s/.*/hbase/        
        RULE:[2:$1@$0](rs@.*EXAMPLE.COM)s/.*/hbase/        
        DEFAULT</value> <description>The mapping from kerberos principal names
        to local OS user names.
</property>                  

To the hdfs-site.xml file on every host in your cluster, you must add the following information:

The XML for these entries:

<property> 
        <name>dfs.permissions</name> 
        <value>true</value> 
        <description> If "true", enable permission checking in
        HDFS. If "false", permission checking is turned
        off, but all other behavior is
        unchanged. Switching from one parameter value to the other does
        not change the mode, owner or group of files or
        directories. </description> 
</property>   

<property> 
        <name>dfs.permissions.supergroup</name> 
        <value>hdfs</value> 
        <description>The name of the group of
        super-users.</description> 
</property>   

<property> 
        <name>dfs.namenode.handler.count</name> 
        <value>100</value> 
        <description>Added to grow Queue size so that more
        client connections are allowed</description> 
</property>   

<property> 
        <name>ipc.server.max.response.size</name> 
        <value>5242880</value> 
</property>   

<property> 
        <name>dfs.block.access.token.enable</name> 
        <value>true</value> 
        <description> If "true", access tokens are used as capabilities
        for accessing datanodes. If "false", no access tokens are checked on
        accessing datanodes. </description> 
</property>   

<property> 
        <name>dfs.namenode.kerberos.principal</name> 
        <value>nn/_HOST@EXAMPLE.COM</value> 
        <description> Kerberos principal name for the
        NameNode </description> 
</property>   

<property> 
        <name>dfs.secondary.namenode.kerberos.principal</name> 
        <value>nn/_HOST@EXAMPLE.COM</value>    
        <description>Kerberos principal name for the secondary NameNode.    
        </description>          
</property>      

<property>     
        <!--cluster variant -->    
        <name>dfs.secondary.http.address</name>    
        <value>ip-10-72-235-178.ec2.internal:50090</value>    
        <description>Address of secondary namenode web server</description>  
</property>    

<property>    
        <name>dfs.secondary.https.port</name>    
        <value>50490</value>    
        <description>The https port where secondary-namenode
        binds</description>  
</property>    

<property>    
        <name>dfs.web.authentication.kerberos.principal</name>    
        <value>HTTP/_HOST@EXAMPLE.COM</value>    
        <description> The HTTP Kerberos principal used by Hadoop-Auth in the HTTP endpoint. 
        The HTTP Kerberos principal MUST start with 'HTTP/' per Kerberos HTTP
        SPNEGO specification.    
        </description>  
</property>    

<property>    
        <name>dfs.web.authentication.kerberos.keytab</name>    
        <value>/etc/security/keytabs/spnego.service.keytab</value>    
        <description>The Kerberos keytab file with the credentials for the HTTP
        Kerberos principal used by Hadoop-Auth in the HTTP endpoint.    
        </description>  
</property>    

<property>    
        <name>dfs.datanode.kerberos.principal</name>    
        <value>dn/_HOST@EXAMPLE.COM</value>  
        <description>        
        The Kerberos principal that the DataNode runs as. "_HOST" is replaced by the real
        host name.    
        </description>  
</property>    

<property>    
        <name>dfs.namenode.keytab.file</name>    
        <value>/etc/security/keytabs/nn.service.keytab</value>  
        <description>        
        Combined keytab file containing the namenode service and host
        principals.    
        </description>  
</property>    

<property>     
        <name>dfs.secondary.namenode.keytab.file</name>    
        <value>/etc/security/keytabs/nn.service.keytab</value>  
        <description>        
        Combined keytab file containing the namenode service and host
        principals.    
        </description>  
</property>    

<property>     
        <name>dfs.datanode.keytab.file</name>    
        <value>/etc/security/keytabs/dn.service.keytab</value>  
        <description>        
        The filename of the keytab file for the DataNode.    
        </description>  
</property>    

<property>    
        <name>dfs.https.port</name>    
        <value>50470</value>  
        <description>The https port where namenode
        binds</description>    
</property>    

<property>    
        <name>dfs.https.address</name>    
        <value>ip-10-111-59-170.ec2.internal:50470</value>  
        <description>The https address where namenode binds</description>    
</property>    

<property>    
        <name>dfs.datanode.data.dir.perm</name>    
        <value>750</value> 
        <description>The permissions that should be there on
        dfs.data.dir directories. The datanode will not come up if the
        permissions are different on existing dfs.data.dir directories. If
        the directories don't exist, they will be created with this
        permission.</description>  
</property>    

<property>  
        <name>dfs.access.time.precision</name>  
        <value>0</value>  
        <description>The access time for HDFS file is precise upto this
        value.The default value is 1 hour. Setting a value of 0
        disables access times for HDFS.  
        </description> 
</property>   

<property>  
        <name>dfs.cluster.administrators</name>  
        <value> hdfs</value>  
        <description>ACL for who all can view the default
        servlets in the HDFS</description> 
</property>   

<property>  
        <name>ipc.server.read.threadpool.size</name>  
        <value>5</value>  
        <description></description> 
</property>   

<property>  
        <name>dfs.namenode.kerberos.internal.spnego.principal</name>  
        <value>${dfs.web.authentication.kerberos.principal}</value> 
</property>   

<property>  
        <name>dfs.secondary.namenode.kerberos.internal.spnego.principal</name>  
        <value>${dfs.web.authentication.kerberos.principal}</value> 
</property> 

In addition, you must set the user on all secure DataNodes:

export HADOOP_SECURE_DN_USER=hdfs
export HADOOP_SECURE_DN_PID_DIR=/grid/0/var/run/hadoop/$HADOOP_SECURE_DN_USER

To the mapred-site.xml file on every host in your cluster, you must add the following information:

The XML for these entries:

<property>  
        <name>mapreduce.jobtracker.kerberos.principal</name>  
        <value>jt/_HOST@EXAMPLE.COM</value>  
        <description> JT
        user name key.  </description> 
</property>   

<property>  
        <name>mapreduce.tasktracker.kerberos.principal</name>   
        <value>tt/_HOST@EXAMPLE.COM</value>  
        <description>tt
        user name key. "_HOST" is replaced by the host name of the task tracker.   
        </description> 
</property>      

<property>    
        <name>hadoop.job.history.user.location</name>    
        <value>none</value>    
        <final>true</final>  
</property>      

<property>   
        <name>mapreduce.jobtracker.keytab.file</name>   
        <value>/etc/security/keytabs/jt.service.keytab</value>   
        <description>       
        The keytab for the jobtracker principal.   
        </description>   
</property>    

<property>   
        <name>mapreduce.tasktracker.keytab.file</name>   
        <value>/etc/security/keytabs/tt.service.keytab</value>    
        <description>The filename of the keytab for the task
        tracker</description>  
</property>    

<property>   
        <name>mapreduce.jobtracker.staging.root.dir</name>   
        <value>/user</value>  
        <description>The Path prefix for where the staging
        directories should be placed. The next level is always the user's name. It
        is a path in the default file system.</description>  
</property>    

<property>      
        <name>mapreduce.tasktracker.group</name>      
        <value>hadoop</value>      
        <description>The group that the task controller uses for accessing the task controller.
        The mapred user must be a member and users should *not* be
        members.</description>    
</property>    

<property>    
        <name>mapreduce.jobtracker.split.metainfo.maxsize</name>    
        <value>50000000</value>     
        <final>true</final>     
        <description>If the size of the split metainfo file is larger than this, the JobTracker
        will fail the job during    
        initialize.   
        </description>  
</property>  

<property>    
        <name>mapreduce.history.server.embedded</name>     
        <value>false</value>    
        <description>Should job history server be embedded within Job tracker process</description>    
        <final>true</final>  
</property>    

<property>    
        <name>mapreduce.history.server.http.address</name>     
        <!--cluster variant -->     
        <value>ip-10-111-59-170.ec2.internal:51111</value>    
        <description>Http address of the history server</description>    
        <final>true</final>  
</property>    

<property>    
        <name>mapreduce.jobhistory.kerberos.principal</name>     
        <!--cluster variant -->  
        <value>jt/_HOST@EXAMPLE.COM</value>    
        <description>Job history user name key. (must map to same user as JT user)</description>  
</property>    

<property>   
        <name>mapreduce.jobhistory.keytab.file</name>     
        <!--cluster variant -->   
        <value>/etc/security/keytabs/jt.service.keytab</value>   
        <description>The keytab for the job history server
        principal.</description>  
</property>   

<property>  
        <name>mapred.jobtracker.blacklist.fault-timeout-window</name>  
        <value>180</value>  
        <description>     3-hour
        sliding window (value is in minutes)  
        </description> 
</property>   

<property>  
        <name>mapred.jobtracker.blacklist.fault-bucket-width</name>  
        <value>15</value>  
        <description>    
        15-minute bucket size (value is in minutes)  
        </description> 
</property>   

<property>  
        <name>mapred.queue.names</name>  
        <value>default</value>   <description>
        Comma separated list of queues configured for this jobtracker.</description> 
</property>    
    

For Hbase to run on a secured cluster, Hbase must be able to authenticate itself to HDFS. To the hbase-site.xml file on your HBase server, you must add the following information. There are no default values; the following are all only examples:

The XML for these entries:

  <property>    
        <name>hbase.master.keytab.file</name>    
        <value>/etc/security/keytabs/hm.service.keytab</value>    
        <description>Full path to the kerberos keytab file to use for logging
        in the configured HMaster server principal.    
        </description>  
</property>  

<property>    
        <name>hbase.master.kerberos.principal</name>    
        <value>hm/_HOST@EXAMPLE.COM</value>    
        <description>Ex. "hbase/_HOST@EXAMPLE.COM". 
        The kerberos principal name that
        should be used to run the HMaster process.  The
        principal name should be in
        the form: user/hostname@DOMAIN.  If "_HOST" is used
        as the hostname portion, it will be replaced with the actual hostname of the running    
        instance.    
        </description>  
</property>  

<property>    
        <name>hbase.regionserver.keytab.file</name>    
        <value>/etc/security/keytabs/rs.service.keytab</value>    
        <description>Full path to the kerberos keytab file to use for logging
        in the configured HRegionServer server principal.    
        </description>  
</property>  

<property>    
        <name>hbase.regionserver.kerberos.principal</name>    
        <value>rs/_HOST@EXAMPLE.COM</value>    
        <description>Ex. "hbase/_HOST@EXAMPLE.COM". 
        The kerberos principal name that
        should be used to run the HRegionServer process. The
        principal name should be in the form: 
        user/hostname@DOMAIN.  If _HOST
        is used as the hostname portion, it will be replaced 
        with the actual hostname of the running
        instance.  An entry for this principal must exist
        in the file specified in hbase.regionserver.keytab.file    
        </description>  
</property>     

<!--Additional configuration specific to HBase security -->
  
<property>    
        <name>hbase.superuser</name>    
        <value>hbase</value>    
        <description>List of users or groups (comma-separated), who are
        allowed full privileges, regardless of stored ACLs, across the cluster. Only
        used when HBase security is enabled.    
        </description>  
</property>    

<property>    
        <name>hbase.coprocessor.region.classes</name>    
        <value></value>    
        <description>A comma-separated list of Coprocessors that are loaded
        by default on all tables. For any override coprocessor method, these classes     
        will be called in order. After implementing your own Coprocessor, 
        just put it in HBase's classpath and add the fully qualified class name here. A
        coprocessor can also be loaded on demand by setting HTableDescriptor.    
        </description>  
</property>    

<property>    
        <name>hbase.coprocessor.master.classes</name>    
        <value></value>    
        <description>A comma-separated list of    
        org.apache.hadoop.hbase.coprocessor.MasterObserver coprocessors that
        are loaded by default on the active HMaster process. For any implemented    
        coprocessor methods, the listed classes will be called in order.
        After implementing your own MasterObserver, just put it in HBase's
        classpath and add the fully qualified class name here.    
        </description>  
</property> 

Hive Metastore supports Kerberos authentication for Thrift clients only. HiveServer does not support Kerberos authentication for any clients:

The XML for these entries:

<property>    
        <name>hive.metastore.sasl.enabled</name>    
        <value>true</value>    
        <description>If true, the metastore thrift interface will be secured with
        SASL.     
        Clients must authenticate with Kerberos.</description>  
</property>    

<property>    
        <name>hive.metastore.kerberos.keytab.file</name>    
        <value>/etc/security/keytabs/hive.service.keytab</value>    
        <description>The path to the Kerberos Keytab file containing the
        metastore thrift server's service principal.</description>  
</property>    

<property>    
        <name>hive.metastore.kerberos.principal</name>    
        <value>hive/_HOST@EXAMPLE.COM</value>    
        <description>The service principal for the metastore thrift server. The
        special string _HOST will be replaced automatically with the correct 
        hostname.</description>  
</property>    

<property>    
        <name>hive.metastore.cache.pinobjtypes</name>    
        <value>Table,Database,Type,FieldSchema,Order</value>    
        <description>List of comma separated metastore object types that should be pinned in
        the cache</description>  
</property>

RULE:[2:$1@$0]([jt]t@.*EXAMPLE.COM)s/.*/mapred/
RULE:[2:$1@$0]([nd]n@.*EXAMPLE.COM)s/.*/hdfs/
RULE:[2:$1@$0](hm@.*EXAMPLE.COM)s/.*/hbase/
RULE:[2:$1@$0](rs@.*EXAMPLE.COM)s/.*/hbase/
DEFAULT