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 Ranger authorization, where credentials are being transmitted back and forth.
To enable TLS/SSL for client applications to 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.
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.
With TLS/SSL enabled for Impala, start impala-shell with the following options:
--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).
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.
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 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.
tlsv1.1: Allow any TLS version of 1.1 or higher.
tlsv1.2: Allow any TLS version of 1.2 or higher.
The default version was changed from 'tlsv1' to 'tlsv1.2' starting in Impala 4.0
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"
See the output of man ciphers for the full set
of keywords and notation allowed in the argument string.
Since Impala 4.2 the default value of --ssl_cipher_list
is a set of ciphers based on Mozilla's intermediate compatibility recommendations
from https://wiki.mozilla.org/Security/Server_Side_TLS.
Prior to Impala 4.2 the default was unset, and Impala used the default
cipher list for the underlying platform.