Enabling Kerberos Authentication for Impala
Impala supports Kerberos authentication. For background information on enabling Kerberos authentication, see Enabling Kerberos Authentication for CDH.
When using Impala in a managed environment, Cloudera Manager automatically completes Kerberos configuration.
In Impala 2.0 and later, user() returns the full Kerberos principal string, such as user@example.com, in a Kerberized environment.
Continue reading:
- Requirements for Using Impala with Kerberos
- Configuring Impala to Support Kerberos Security
- Enabling Kerberos for Impala with a Proxy Server
- Enabling Impala Delegation for Kerberos Users
- Using TLS/SSL with Business Intelligence Tools
- Enabling Access to Internal Impala APIs for Kerberos Users
- Kerberos-Related Memory Overhead for Large Clusters
- Mapping Kerberos Principals to Short Names for Impala
An alternative form of authentication you can use is LDAP, described in Enabling LDAP Authentication for Impala.
Requirements for Using Impala with Kerberos
-
If you plan to use Impala in your cluster, you must configure your KDC to allow tickets to be renewed, and you must configure krb5.conf to request renewable tickets. Typically, you can do this by adding the max_renewable_life setting to your realm in kdc.conf, and by adding the renew_lifetime parameter to the libdefaults section of krb5.conf.
For more information about renewable tickets, see the Kerberos documentation.
-
The Impala Web UI does not support Kerberos authentication.
-
You cannot use the Impala resource management feature on a cluster that has Kerberos authentication enabled.
Impala supports the Cloudera ODBC driver and the Kerberos interface provided. To use Kerberos through the ODBC driver, the host type must be set depending on the level of the ODBD driver:
- SecImpala for the ODBC 1.0 driver.
- SecBeeswax for the ODBC 1.2 driver.
- Blank for the ODBC 2.0 driver or higher, when connecting to a secure cluster.
- HS2NoSasl for the ODBC 2.0 driver or higher, when connecting to a non-secure cluster.
To enable Kerberos in the Impala shell, start the impala-shell command using the -k flag.
Configuring Impala to Support Kerberos Security
Enabling Kerberos authentication for Impala involves steps that can be summarized as follows:
- Creating service principals for Impala and the HTTP service. Principal names take the form: serviceName/fully.qualified.domain.name@KERBEROS.REALM
- Creating, merging, and distributing key tab files for these principals.
- Editing /etc/default/impala (in cluster not managed by Cloudera Manager), or editing the Security settings in the Cloudera Manager interface, to accommodate Kerberos authentication.
Enabling Kerberos for Impala with a Proxy Server
A common configuration for Impala with High Availability is to use a proxy server to submit requests to the actual impalad daemons on different hosts in the cluster. This configuration avoids connection problems in case of machine failure, because the proxy server can route new requests through one of the remaining hosts in the cluster. This configuration also helps with load balancing, because the additional overhead of being the "coordinator node" for each query is spread across multiple hosts.
Although you can set up a proxy server with or without Kerberos authentication, typically users set up a secure Kerberized configuration. For information about setting up a proxy server for Impala, including Kerberos-specific steps, see Using Impala through a Proxy for High Availability.
Enabling Impala Delegation for Kerberos Users
See Configuring Impala Delegation for Hue and BI Tools for details about the delegation feature that lets certain users submit queries using the credentials of other users.
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.
Enabling Access to Internal Impala APIs for Kerberos Users
For applications that need direct access to Impala APIs, without going through the HiveServer2 or Beeswax interfaces, you can specify a list of Kerberos users who are allowed to call those APIs. By default, the impala and hdfs users are the only ones authorized for this kind of access. Any users not explicitly authorized through the internal_principals_whitelist configuration setting are blocked from accessing the APIs. This setting applies to all the Impala-related daemons, although currently it is primarily used for HDFS to control the behavior of the catalog server.
Kerberos-Related Memory Overhead for Large Clusters
Failed to obtain Kerberos ticket for principal: <varname>principal_details</varname> Failed to execute shell cmd: 'kinit -k -t <varname>keytab_details</varname>', error was: Error(12): Cannot allocate memory
echo 1 > /proc/sys/vm/overcommit_memory
vm.overcommit_memory=1
Then run sysctl -p. No reboot is needed.
Mapping Kerberos Principals to Short Names for Impala
In CDH 5.8 / Impala 2.6 and higher, Impala recognizes the auth_to_local setting, specified through the Cloudera Manager setting Additional Rules to Map Kerberos Principals to Short Names. This feature is disabled by default, to avoid an unexpected change in security-related behavior. To enable it, select the Use HDFS Rules to Map Kerberos Principals to Short Names checkbox to enable the service-wide load_auth_to_local_rules configuration setting. Then restart the Impala service. See Using Auth-to-Local Rules to Isolate Cluster Users for general information about this feature.
<< Impala Authentication | ©2016 Cloudera, Inc. All rights reserved | Enabling LDAP Authentication for Impala >> |
Terms and Conditions Privacy Policy |