This is the documentation for Cloudera Enterprise 5.8.x. Documentation for other versions is available at Cloudera Documentation.

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.
  Important:
  • You can use either Cloudera Manager or the following command-line instructions to complete this configuration.
  • This information applies specifically to CDH 5.8.x. If you use an earlier version of CDH, see the documentation for that version located at Cloudera Documentation.

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:
    Table 1. Impala SSL Properties
    Property Description
    Enable TLS/SSL for Impala Client Services 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)).
    SSL/TLS Certificate for Clients Local path to the X509 certificate that identifies the Impala daemon to clients during TLS/SSL connections. This file must be in PEM format.
    SSL/TLS Private Key for Clients Local path to the private key that matches the certificate specified in the Certificate for Clients. This file must be in PEM format.
    SSL/TLS Private Key Password for Clients A shell command for Impala to run on startup to retrieve the password for a password-protected private key file. The output of the command is truncated to a maximum of 1024 bytes, and any trailing whitespace (such as spaces or newline characters) is trimmed. If the command exits with an error, Impala does not start. If the password is incorrect, clients cannot connect to the server regardless of whether the public key is correct.
    SSL/TLS CA Certificate Must be specified for TLS/SSL encryption to be enabled for communication between internal Impala components.
    SSL/TLS Certificate for Impala component Webserver There are three of these configuration settings, one each for "Impala Daemon", "Catalog Server", and "Statestore". 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. This file must be in PEM format.
  6. Click Save Changes to commit the changes.
  7. Restart the Impala service.

For information on configuring TLS/SSL communication with the impala-shell interpreter, see Configuring TLS/SSL Communication for the Impala Shell.

Using the Command Line

To enable SSL for when client applications connect to Impala, add both of the following flags to the impalad startup options:

  • --ssl_server_certificate: the full path to the server certificate, on the local filesystem.
  • --ssl_private_key: the full path to the server private key, on the local filesystem.

In CDH 5.5 / Impala 2.3 and higher, Impala can also use SSL for its own internal communication between the impalad, statestored, and catalogd daemons. To enable this additional SSL encryption, set the --ssl_server_certificate and --ssl_private_key flags in the startup options for impalad, catalogd, and statestored, and also add the --ssl_client_ca_certificate flag for all three of those daemons.

  Warning: Prior to CDH 5.5.2 / Impala 2.3.2, you could enable Kerberos authentication between Impala internal components, or SSL encryption between Impala internal components, but not both at the same time. This restriction has now been lifted. See IMPALA-2598 to see the maintenance releases for different levels of CDH where the fix has been published.

If either of these flags are set, both must be set. In that case, Impala starts listening for Beeswax and HiveServer2 requests on SSL-secured ports only. (The port numbers stay the same; see Ports Used by Impala for details.)

Since Impala uses passphrase-less certificates in PEM format, you can reuse a host's existing Java keystore by converting it to the PEM format. For instructions, see Conversion from Java Keystore to OpenSSL.

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 SSL enabled for Impala, you use the following options when starting the impala-shell interpreter:

  • --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).

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.

Page generated July 8, 2016.