Configuring TLS/SSL for Impala

Impala supports TLS/SSL network encryption, between Impala and client programs, and between the Impala-related daemons running on different nodes in the cluster. This feature is important when you also use other features such as Kerberos authentication or Sentry authorization, where credentials are being transmitted back and forth.

Using Cloudera Manager

To configure Impala to listen for Beeswax and HiveServer2 requests on TLS/SSL-secured ports:
  1. Open the Cloudera Manager Admin Console and go to the Impala service.
  2. Click the Configuration tab.
  3. Select Scope > Impala (Service-Wide).
  4. Select Category > Security.
  5. Edit the following properties:
    Impala SSL Properties
    Property Description
    Enable TLS/SSL for Impala Encrypt communication between clients (like ODBC, JDBC, and the Impala shell) and the Impala daemon using Transport Layer Security (TLS) (formerly known as Secure Socket Layer (SSL)).
    Impala TLS/SSL Server Certificate File (PEM Format) Local path to the X509 certificate that identifies the Impala daemon to clients during TLS/SSL connections. This file must be in PEM format.
    Impala TLS/SSL Server Private Key File (PEM Format) Local path to the private key that matches the certificate specified in the Certificate for Clients. This file must be in PEM format.
    Impala TLS/SSL Private Key Password The password for the private key in the Impala TLS/SSL Server Certificate and Private Key file. If left blank, the private key is not protected by a password.
    Impala TLS/SSL CA Certificate The location on disk of the certificate, in PEM format, used to confirm the authenticity of SSL/TLS servers that the Impala daemons might connect to. Because the Impala daemons connect to each other, this should also include the CA certificate used to sign all the SSL/TLS Certificates. Without this parameter, SSL/TLS between Impala daemons will not be enabled.
  6. Click Save Changes to commit the changes.
  7. Select each scope, one each for "Impala Daemon", "Catalog Server", and "Statestore", and repeat the above steps. Each of these Impala components has its own internal web server that powers the associated web UI with diagnostic information. The configuration setting represents the local path to the X509 certificate that identifies the web server to clients during TLS/SSL connections.
  8. Restart the Impala service.

Configuring TLS/SSL Communication for the Impala Shell

Typically, a client program has corresponding configuration properties in Cloudera Manager to verify that it is connecting to the right server. For example, with TLS/SSL enabled for Impala, you use the following options when starting impala-shell:

  • --ssl: enables TLS/SSL for impala-shell.
  • --ca_cert: the local pathname pointing to the third-party CA certificate, or to a copy of the server certificate for self-signed server certificates.

If --ca_cert is not set, impala-shell enables TLS/SSL, but does not validate the server certificate. This is useful for connecting to a known-good Impala that is only running over TLS/SSL, when a copy of the certificate is not available (such as when debugging customer installations).

For impala-shell to successfully connect to an Impala cluster that has the minimum allowed TLS/SSL version set to 1.2 (--ssl_minimum_version=tlsv1.2), the Python version on the cluster that impala-shell runs on must be 2.7.9 or higher (or a vendor-provided Python version with the required support. Some vendors patched Python 2.7.5 versions on Red Hat Enterprise Linux 7 and derivatives).

Using TLS/SSL with Business Intelligence Tools

You can use Kerberos authentication, TLS/SSL encryption, or both to secure connections from JDBC and ODBC applications to Impala. See Configuring Impala to Work with JDBC and Configuring Impala to Work with ODBC for details.

Prior to CDH 5.7 / Impala 2.5, the Hive JDBC driver did not support connections that use both Kerberos authentication and SSL encryption. If your cluster is running an older release that has this restriction, to use both of these security features with Impala through a JDBC application, use the Cloudera JDBC Connector as the JDBC driver.

Specifying TLS/SSL Minimum Allowed Version and Ciphers

Depending on your cluster configuration and the security practices in your organization, you might need to restrict the allowed versions of TLS/SSL used by Impala. Older TLS/SSL versions might have vulnerabilities or lack certain features. In CDH 5.13 / Impala 2.10, you can use startup options for the impalad, catalogd, and statestored daemons to specify a minimum allowed version of TLS/SSL.

Specify one of the following values for the --ssl_minimum_version configuration setting:

  • tlsv1: Allow any TLS version of 1.0 or higher. This setting is the default when TLS/SSL is enabled.

  • tlsv1.1: Allow any TLS version of 1.1 or higher.

  • tlsv1.2: Allow any TLS version of 1.2 or higher.

Along with specifying the version, you can also specify the allowed set of TLS ciphers by using the --ssl_cipher_list configuration setting. The argument to this option is a list of keywords, separated by colons, commas, or spaces, and optionally including other notation. For example:

--ssl_cipher_list="RC4-SHA,RC4-MD5"

By default, the cipher list is empty, and Impala uses the default cipher list for the underlying platform. See the output of man ciphers for the full set of keywords and notation allowed in the argument string.