Important:

This section describes how to configure security for the Hive metastore server. If you are using HiveServer2, see HiveServer2 Security Configuration.

Here is a summary of Hive metastore server security in CDH 5:

• No additional configuration is required to run Hive on top of a security-enabled Hadoop cluster in standalone mode using a local or embedded metastore.
• HiveServer does not support Kerberos authentication for clients. While it is possible to run HiveServer with a secured Hadoop cluster, doing so creates a security hole since HiveServer does not authenticate the Thrift clients that connect to it. Instead, you can use HiveServer2 HiveServer2 Security Configuration.
• The Hive metastore server supports Kerberos authentication for Thrift clients. For example, you can configure a standalone Hive metastore server instance to force clients to authenticate with Kerberos by setting the following properties in the hive-site.xml configuration file used by the metastore server:

  <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/hive/conf/hive.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@YOUR-REALM.COM</value>
    <description>The service principal for the metastore thrift server. The special string _HOST will be replaced automatically with the correct host name.</description>
  </property>

    Note:

  The values shown above for the hive.metastore.kerberos.keytab.file and hive.metastore.kerberos.principal properties are examples which you will need to replace with the appropriate values for your cluster. Also note that the Hive keytab file should have its access permissions set to 600 and be owned by the same account that is used to run the Metastore server, which is the hive user by default.

• Requests to access the metadata are fulfilled by the Hive metastore impersonating the requesting user. This includes read access to the list of databases, tables, properties of each table such as their HDFS location and file type. You can restrict access to the Hive metastore service by allowing it to impersonate only a subset of Kerberos users. This can be done by setting the hadoop.proxyuser.hive.groups property in core-site.xml on the Hive metastore host.
  For example, if you want to give the hive user permission to impersonate members of groups hive and user1:

  <property>
  <name>hadoop.proxyuser.hive.groups</name>
  <value>hive,user1</value>
  </property>

  In this example, the Hive metastore can impersonate users belonging to only the hive and user1 groups. Connection requests from users not belonging to these groups will be rejected.