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 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 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 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 Impala 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 using the openssl toolkit to convert it to the PEM format.

Configuring TLS/SSL Communication for the Impala Shell

With SSL enabled for Impala, 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 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, use an alternative JDBC driver that supports both of these security features.