<a href="../../hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html">Compatibilty between Hadoop 1.x and Hadoop 2.x</a>
<a href="http://maven.apache.org/" title="Built by Maven" class="poweredBy">
<img alt="Built by Maven" src="./images/logos/maven-feather.png"/>
</a>
</div>
</div>
<div id="bodyColumn">
<div id="contentBox">
<!-- Licensed under the Apache License, Version 2.0 (the "License"); --><!-- you may not use this file except in compliance with the License. --><!-- You may obtain a copy of the License at --><!-- --><!-- http://www.apache.org/licenses/LICENSE-2.0 --><!-- --><!-- Unless required by applicable law or agreed to in writing, software --><!-- distributed under the License is distributed on an "AS IS" BASIS, --><!-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. --><!-- See the License for the specific language governing permissions and --><!-- limitations under the License. See accompanying LICENSE file. --><ul>
<li><a href="#Hadoop_in_Secure_Mode">Hadoop in Secure Mode</a>
<ul>
<li><a href="#Introduction">Introduction</a></li>
<li><a href="#Authentication">Authentication</a>
<ul>
<li><a href="#End_User_Accounts">End User Accounts</a></li>
<li><a href="#User_Accounts_for_Hadoop_Daemons">User Accounts for Hadoop Daemons</a></li>
<li><a href="#Kerberos_principals_for_Hadoop_Daemons_and_Users">Kerberos principals for Hadoop Daemons and Users</a></li>
<li><a href="#Mapping_from_Kerberos_principal_to_OS_user_account">Mapping from Kerberos principal to OS user account</a></li>
<li><a href="#Mapping_from_user_to_group">Mapping from user to group</a></li>
<h2>Hadoop in Secure Mode<a name="Hadoop_in_Secure_Mode"></a></h2>
<div class="section">
<h3>Introduction<a name="Introduction"></a></h3>
<p>This document describes how to configure authentication for Hadoop in secure mode.</p>
<p>By default Hadoop runs in non-secure mode in which no actual authentication is required. By configuring Hadoop runs in secure mode, each user and service needs to be authenticated by Kerberos in order to use Hadoop services.</p>
<p>Security features of Hadoop consist of <a href="#Authentication">authentication</a>, <a href="./ServiceLevelAuth.html">service level authorization</a>, <a href="./HttpAuthentication.html">authentication for Web consoles</a> and <a href="#Data_confidentiality">data confidenciality</a>.</p></div>
<h4>End User Accounts<a name="End_User_Accounts"></a></h4>
<p>When service level authentication is turned on, end users using Hadoop in secure mode needs to be authenticated by Kerberos. The simplest way to do authentication is using <tt>kinit</tt> command of Kerberos.</p></div>
<div class="section">
<h4>User Accounts for Hadoop Daemons<a name="User_Accounts_for_Hadoop_Daemons"></a></h4>
<p>Ensure that HDFS and YARN daemons run as different Unix users, e.g. <tt>hdfs</tt> and <tt>yarn</tt>. Also, ensure that the MapReduce JobHistory server runs as different user such as <tt>mapred</tt>.</p>
<p>It's recommended to have them share a Unix group, for e.g. <tt>hadoop</tt>. See also "<a href="#Mapping_from_user_to_group">Mapping from user to group</a>" for group management.</p>
<h4>Kerberos principals for Hadoop Daemons and Users<a name="Kerberos_principals_for_Hadoop_Daemons_and_Users"></a></h4>
<p>For running hadoop service daemons in Hadoop in secure mode, Kerberos principals are required. Each service reads auhenticate information saved in keytab file with appropriate permission.</p>
<p>HTTP web-consoles should be served by principal different from RPC's one.</p>
<p>Subsections below shows the examples of credentials for Hadoop services.</p>
<div class="section">
<h5>HDFS<a name="HDFS"></a></h5>
<p>The NameNode keytab file, on the NameNode host, should look like the following:</p>
4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)</pre></div></div></div>
<div class="section">
<h4>Mapping from Kerberos principal to OS user account<a name="Mapping_from_Kerberos_principal_to_OS_user_account"></a></h4>
<p>Hadoop maps Kerberos principal to OS user account using the rule specified by <tt>hadoop.security.auth_to_local</tt> which works in the same way as the <tt>auth_to_local</tt> in <a class="externalLink" href="http://web.mit.edu/Kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html">Kerberos configuration file (krb5.conf)</a>.</p>
<p>By default, it picks the first component of principal name as a user name if the realms matches to the <tt>defalut_realm</tt> (usually defined in /etc/krb5.conf). For example, <tt>host/full.qualified.domain.name@REALM.TLD</tt> is mapped to <tt>host</tt> by default rule.</p></div>
<div class="section">
<h4>Mapping from user to group<a name="Mapping_from_user_to_group"></a></h4>
<p>Though files on HDFS are associated to owner and group, Hadoop does not have the definition of group by itself. Mapping from user to group is done by OS or LDAP.</p>
<p>You can change a way of mapping by specifying the name of mapping provider as a value of <tt>hadoop.security.group.mapping</tt> See <a href="../hadoop-hdfs/HdfsPermissionsGuide.html">HDFS Permissions Guide</a> for details.</p>
<p>Practically you need to manage SSO environment using Kerberos with LDAP for Hadoop in secure mode.</p></div>
<div class="section">
<h4>Proxy user<a name="Proxy_user"></a></h4>
<p>Some products such as Apache Oozie which access the services of Hadoop on behalf of end users need to be able to impersonate end users. You can configure proxy user using properties <tt>hadoop.proxyuser.$<a name="superuser">superuser</a>.hosts</tt> and <tt>hadoop.proxyuser.$<a name="superuser">superuser</a>.groups</tt>.</p>
<p>For example, by specifying as below in core-site.xml, user named <tt>oozie</tt> accessing from any host can impersonate any user belonging to any group.</p>
<p>Because the data transfer protocol of DataNode does not use the RPC framework of Hadoop, DataNode must authenticate itself by using privileged ports which are specified by <tt>dfs.datanode.address</tt> and <tt>dfs.datanode.http.address</tt>. This authentication is based on the assumption that the attacker won't be able to get root privileges.</p>
<p>When you execute <tt>hdfs datanode</tt> command as root, server process binds privileged port at first, then drops privilege and runs as the user account specified by <tt>HADOOP_SECURE_DN_USER</tt>. This startup process uses jsvc installed to <tt>JSVC_HOME</tt>. You must specify <tt>HADOOP_SECURE_DN_USER</tt> and <tt>JSVC_HOME</tt> as environment variables on start up (in hadoop-env.sh).</p></div></div>
<h4>Data Encryption on RPC<a name="Data_Encryption_on_RPC"></a></h4>
<p>The data transfered between hadoop services and clients. Setting <tt>hadoop.rpc.protection</tt> to <tt>"privacy"</tt> in the core-site.xml activate data encryption.</p></div>
<div class="section">
<h4>Data Encryption on Block data transfer.<a name="Data_Encryption_on_Block_data_transfer."></a></h4>
<p>You need to set <tt>dfs.encrypt.data.transfer</tt> to <tt>"true"</tt> in the hdfs-site.xml in order to activate data encryption for data transfer protocol of DataNode.</p></div>
<div class="section">
<h4>Data Encryption on HTTP<a name="Data_Encryption_on_HTTP"></a></h4>
<p>Data transfer between Web-console and clients are protected by using SSL(HTTPS).</p></div></div>
<p>In order to turn on RPC authentication in hadoop, set the value of <tt>hadoop.security.authentication</tt> property to <tt>"kerberos"</tt>, and set security related settings listed below appropriately.</p>
<p>The following properties should be in the <tt>core-site.xml</tt> of all the nodes in the cluster.</p>
<table border="1" class="bodyTable"><caption>Configuration for <tt>conf/core-site.xml</tt>
<td align="left"><i>authentication</i> : authentication only (default)  <br /><i>integrity</i> : integrity check in addition to authentication  <br /><i>privacy</i> : data encryption in addition to integrity</td></tr>
<td align="left">The value is string containing new line characters. See <a class="externalLink" href="http://web.mit.edu/Kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html">Kerberos documentation</a> for format for <i>exp</i>.</td></tr>
<td align="left">Enable HDFS block access tokens for secure operations.</td></tr>
<tr class="a">
<td align="left"><tt>dfs.https.enable</tt></td>
<td align="left"><i>true</i></td>
<td align="left">This value is deprecated. Use dfs.http.policy</td></tr>
<tr class="b">
<td align="left"><tt>dfs.http.policy</tt></td>
<td align="left"><i>HTTP_ONLY</i> or <i>HTTPS_ONLY</i> or <i>HTTP_AND_HTTPS</i></td>
<td align="left">HTTPS_ONLY turns off http access. This option takes precedence over the deprecated configuration dfs.https.enable and hadoop.ssl.enabled.</td></tr>
<td align="left">Secure DataNode must use privileged port in order to assure that the server was started securely. This means that the server must be started via jsvc.</td></tr>
<td align="left">Secure DataNode must use privileged port in order to assure that the server was started securely. This means that the server must be started via jsvc.</td></tr>
<td align="left">The path to the executable of Linux container executor.</td></tr></table></div>
<div class="section">
<h4>Configuration for WebAppProxy<a name="Configuration_for_WebAppProxy"></a></h4>
<p>The <tt>WebAppProxy</tt> provides a proxy between the web applications exported by an application and an end user. If security is enabled it will warn users before accessing a potentially unsafe web application. Authentication and authorization using the proxy is handled just like any other privileged web application.</p>
<table border="1" class="bodyTable"><caption>Configuration for <tt>conf/yarn-site.xml</tt>
<td align="left"><tt>WebAppProxy</tt> host:port for proxy to AM web apps.</td>
<td align="left"><i>host:port</i> if this is the same as <tt>yarn.resourcemanager.webapp.address</tt> or it is not defined then the <tt>ResourceManager</tt> will run the proxy otherwise a standalone proxy server will need to be launched.</td></tr>
<td align="left">The default executor which YARN uses to manage container execution. The container process has the same Unix user as the NodeManager.</td></tr>
<td align="left">Supported only on GNU/Linux, this executor runs the containers as either the YARN user who submitted the application (when full security is enabled) or as a dedicated user (defaults to nobody) when full security is not enabled. When full security is enabled, this executor requires all user accounts to be created on the cluster nodes where the containers are launched. It uses a <i>setuid</i> executable that is included in the Hadoop distribution. The NodeManager uses this executable to launch and kill containers. The setuid executable switches to the user who has submitted the application and launches or kills the containers. For maximum security, this executor sets up restricted permissions and user/group ownership of local files and directories used by the containers such as the shared objects, jars, intermediate files, log files etc. Particularly note that, because of this, except the application owner and NodeManager, no other user can access any of the local files/directories including those localized as part of the distributed cache.</td></tr></table>
<p>To build the LinuxContainerExecutor executable run:</p>
<p>The path passed in <tt>-Dcontainer-executor.conf.dir</tt> should be the path on the cluster nodes where a configuration file for the setuid executable should be located. The executable should be installed in $HADOOP_YARN_HOME/bin.</p>
<p>The executable must have specific permissions: 6050 or --Sr-s--- permissions user-owned by <i>root</i> (super-user) and group-owned by a special group (e.g. <tt>hadoop</tt>) of which the NodeManager Unix user is the group member and no ordinary application user is. If any application user belongs to this special group, security will be compromised. This special group name should be specified for the configuration property <tt>yarn.nodemanager.linux-container-executor.group</tt> in both <tt>conf/yarn-site.xml</tt> and <tt>conf/container-executor.cfg</tt>.</p>
<p>For example, let's say that the NodeManager is run as user <i>yarn</i> who is part of the groups users and <i>hadoop</i>, any of them being the primary group. Let also be that <i>users</i> has both <i>yarn</i> and another user (application submitter) <i>alice</i> as its members, and <i>alice</i> does not belong to <i>hadoop</i>. Going by the above description, the setuid/setgid executable should be set 6050 or --Sr-s--- with user-owner as <i>yarn</i> and group-owner as <i>hadoop</i> which has <i>yarn</i> as its member (and not <i>users</i> which has <i>alice</i> also as its member besides <i>yarn</i>).</p>
<p>The LinuxTaskController requires that paths including and leading up to the directories specified in <tt>yarn.nodemanager.local-dirs</tt> and <tt>yarn.nodemanager.log-dirs</tt> to be set 755 permissions as described above in the table on permissions on directories.</p>
<p>The executable requires a configuration file called <tt>container-executor.cfg</tt> to be present in the configuration directory passed to the mvn target mentioned above.</p>
<p>The configuration file must be owned by the user running NodeManager (user <tt>yarn</tt> in the above example), group-owned by anyone and should have the permissions 0400 or r--------.</p>
<p>The executable requires following configuration items to be present in the <tt>conf/container-executor.cfg</tt> file. The items should be mentioned as simple key=value pairs, one per-line:</p>
<table border="1" class="bodyTable"><caption>Configuration for <tt>conf/yarn-site.xml</tt>
<td align="left">Unix group of the NodeManager. The group owner of the <i>container-executor</i> binary should be this group. Should be same as the value with which the NodeManager is configured. This configuration is required for validating the secure access of the <i>container-executor</i> binary.</td></tr>