Cloudera Enterprise 5.15.x | Other versions

Configuring Encrypted Communication Between HiveServer2 and Client Drivers

Starting with CDH 5.5, encryption between HiveServer2 and its clients has been decoupled from Kerberos authentication. (Prior to CDH 5.5, SASL QOP encryption for JDBC client drivers required connections authenticated by Kerberos.) De-coupling the authentication process from the transport-layer encryption process means that HiveServer2 can support two different approaches to encryption between the service and its clients (Beeline, JDBC/ODBC) regardless of whether Kerberos is being used for authentication, specifically:

Unlike TLS/SSL, SASL QOP encryption does not require certificates and is aimed at protecting core Hadoop RPC communications. However, SASL QOP may have performance issues when handling large amounts of data, so depending on your usage patterns, TLS/SSL may be a better choice. See the following topics for details about configuring HiveServer2 services and clients for TLS/SSL and SASL QOP encryption.

Continue reading:

Configuring TLS/SSL Encryption for HiveServer2

HiveServer2 can be configured to support TLS/SSL connections from JDBC/ODBC clients using the Cloudera Manager Admin Console (for clusters that run in the context of Cloudera Manager Server), or manually using the command line.

Requirements and Assumptions

Whether you use Cloudera Manager Admin Console or manually modify the Hive configuration file for TLS/SSL encryption, the steps assume that the HiveServer2 node in the cluster has the necessary server key, certificate, keystore, and trust store set up on the host system. For details, see any of the following:
The configuration paths and filenames shown below assume that hostname variable ($(hostname -f)-server.jks) was used with Java keytool commands to create keystore, as shown in this example: 
$ sudo keytool -genkeypair -alias $(hostname -f)-server -keyalg RSA -keystore \
/opt/cloudera/security/pki/$(hostname -f)-server.jks -keysize 2048 -dname \
"CN=$(hostname -f),OU=dept-name-optional,O=company-name,L=city,ST=state,C=two-digit-nation" \
-storepass password -keypass password

See the appropriate How-To guide from the above list for more information.

Using Cloudera Manager to Enable TLS/SSL

To configure TLS/SSL for Hive in clusters managed by Cloudera Manager:
  1. Log in to the Cloudera Manager Admin Console.
  2. Select Clusters > Hive.
  3. Click the Configuration tab.
  4. Select Hive (Service-Wide) for the Scope filter.
  5. Select Security for the Category filter. The TLS/SSL configuration options display.
  6. Enter values for your cluster as follows:
    Property Description
    Enable TLS/SSL for HiveServer2 Click the checkbox to enable encrypted client-server communications between HiveServer2 and its clients using TLS/SSL.
    HiveServer2 TLS/SSL Server JKS Keystore File Location Enter the path to the Java keystore on the host system. For example: 
    /opt/cloudera/security/pki/server-name-server.jks
    HiveServer2 TLS/SSL Server JKS Keystore File Password Enter the password for the keystore that was passed at the Java keytool command-line when the key and keystore were created. As detailed in How To Obtain and Deploy Keys and Certificates for TLS/SSL, the password for the keystore must be the same as the password for the key.
    HiveServer2 TLS/SSL Certificate Trust Store File Enter the path to the Java trust store on the host system. Cloudera clusters are typically configured to use the alternative trust store, jssecacerts, set up at $JAVA_HOME/jre/lib/security/jssecacerts.
    For example:

    The entry field for certificate trust store password has been left empty because the trust store is typically not password protected—it contains no keys, only publicly available certificates that help establish the chain of trust during the TLS/SSL handshake. In addition, reading the trust store does not require the password.
  7. Click Save Changes.
  8. Restart the Hive service.

Using the Command Line to Enable TLS/SSL

To configure TLS/SSL for Hive in CDH clusters (without Cloudera Manager), add the properties to enable TLS/SSL and to specify the path to the keystore and the keystore password to the HiveServer2 configuration file (hive-site.xml) as shown below. The keystore must contain the server certificate and the host must meet all Requirements and Assumptions listed above. 
<property>
  <name>hive.server2.use.SSL</name>
  <value>true</value>
</property>
 
<property>
  <name>hive.server2.keystore.path</name>
  <value>/opt/cloudera/security/pki/keystore-for-this-server.jks</value>
</property>

<property>
  <name>hive.server2.keystore.password</name>
  <value>password</value>
</property>

Client Connections to HiveServer2 Over TLS/SSL

Clients connecting to a HiveServer2 over TLS/SSL must be able to access the trust store on the HiveServer2 host system. The trust store contains intermediate and other certificates that the client uses to establish a chain of trust and verify server certificate authenticity. The trust store is typically not password protected.

  Note: The trust store may have been password protected to prevent its contents from being modified. However, password protected trust stores can be read from without using the password.
The client needs the path to the trust store when attempting to connect to HiveServer2 using TLS/SSL. This can be specified using two different approaches, as follows:
  • Pass the path to the trust store each time you connect to HiveServer in the JDBC connection string: 
    jdbc:hive2://fqdn.example.com:10000/default;ssl=true;\
sslTrustStore=$JAVA_HOME/jre/lib/security/jssecacerts;trustStorePassword=extraneous
    or,
  • Set the path to the trust store one time in the Java system javax.net.ssl.trustStore property: 
    java -Djavax.net.ssl.trustStore=/usr/java/jdk1.7.0_67-cloudera/jre/lib/security/jssecacerts \
-Djavax.net.ssl.trustStorePassword=extraneous MyClass \
jdbc:hive2://fqdn.example.com:10000/default;ssl=true

Configuring SASL Encryption for HiveServer2

Communications between Hive JDBC or ODBC drivers and HiveServer2 can be encrypted using SASL, a framework for authentication and data security rather than a protocol like TLS/SSL. Support for SASL (Simple Authentication and Security Layer) in HiveServer2 preceded the support for TLS/SSL. SASL offers three different Quality of Protection (QOP) levels as shown in the table:
auth Default. Authentication only.
auth-int Authentication with integrity protection. Signed message digests (checksums) verify the integrity of messages sent between client and server.
auth-conf Authentication with confidentiality (transport-layer encryption). Use this setting for encrypted communications from clients to HiveServer2.
To support encryption for communications between client and server processes, specify the QOP auth-conf setting for the SASL QOP property in the HiveServer2 configuration file (hive-site.xml). For example, 
<property>
  <name>hive.server2.thrift.sasl.qop</name>
  <value>auth-conf</value>
</property>

Client Connections to HiveServer2 Using SASL

The client connection string must match the parameter value specified for the HiveServer2 configuration. This example shows how to specify encryption for the Beeline client in the JDBC connection URL: 
beeline> !connect jdbc:hive2://fqdn.example.com:10000/default;  \
principal=hive/_HOST@EXAMPLE.COM;sasl.qop=auth-conf
The _HOST is a wildcard placeholder that gets automatically replaced with the fully qualified domain name (FQDN) of the server running the HiveServer2 daemon process.
Page generated May 18, 2018.