Authentication is the process of allowing only specified named users to access the server (in this case, the Impala server). This feature is crucial for any production deployment, to prevent misuse, tampering, or excessive load on the server. Impala users LDAP for authentication, verifying the credentials of each user who connects through impala-shell, Hue, a Business Intelligence tool, JDBC or ODBC application, and so on.

  Note: Regardless of the authentication mechanism used, Impala always creates HDFS directories and data files owned by the same user (typically impala). To implement user-level access to different databases, tables, columns, partitions, and so on, use the Sentry authorization feature, as explained in Enabling Sentry Authorization for Impala.

Versions:

Authentication against LDAP servers is available in Impala 1.2.2 and higher. Impala 1.4.0 adds support for secure LDAP authentication through SSL and TLS.

Other aspects of authentication:

Only client->Impala connections can be authenticated by LDAP. Kerberos is the only authentication mechanism for connections between internal components, such as between the Impala, statestore, and catalog daemons. See Enabling Kerberos Authentication for Impala for how to set up Kerberos for Impala.

Server-side LDAP setup:

These requirements apply on the server side when configuring and starting Impala:

To enable LDAP authentication, set the following startup options for impalad:

• --enable_ldap_auth enables LDAP-based authentication between the client and Impala.
• --ldap_uri sets the URI of the LDAP server to use. Typically, the URI is prefixed with ldap://. In Impala 1.4.0 and higher, you can specify secure SSL-based LDAP transport by using the prefix ldaps://. The URI can optionally specify the port, for example: ldap://ldap_server.cloudera.com:389 or ldaps://ldap_server.cloudera.com:636. (389 and 636 are the default ports for non-SSL and SSL LDAP connections, respectively.)
• For ldaps:// connections secured by SSL, --ldap_ca_certificate="/path/to/certificate/pem" specifies the location of the certificate in standard .PEM format. Store this certificate on the local filesystem, in a location that only the impala user and other trusted users can read.

Support for custom bind strings:

When Impala connects to LDAP it issues a bind call to the LDAP server to authenticate as the connected user. Impala clients, including the Impala shell, provide the short name of the user to Impala. This is necessary so that Impala can use Sentry for role-based access, which uses short names.

However, LDAP servers often require more complex, structured usernames for authentication. Impala supports three ways of transforming the short name (for example, 'henry') to a more complicated string. If necessary, specify one of the following configuration options when starting the impalad daemon on each data node:

• --ldap_domain: Replaces the username with a string username@ldap_domain.
• --ldap_baseDN: Replaces the username with a "distinguished name" (DN) of the form: uid=userid,ldap_baseDN. (This is equivalent to a Hive option).
• --ldap_bind_pattern: This is the most general option, and replaces the username with the string ldap_bind_pattern where all instances of the string #UID are replaced with userid. For example, an ldap_bind_pattern of "user=#UID,OU=foo,CN=bar" with a username of henry will construct a bind name of "user=henry,OU=foo,CN=bar".

These options are mutually exclusive; Impala does not start if more than one of these options is specified.

Secure LDAP connections:

To avoid sending credentials over the wire in cleartext, you must configure a secure connection between both the client and Impala, and between Impala and the LDAP server. The secure connection could use SSL or TLS.

Secure LDAP connections through SSL:

For SSL-enabled LDAP connections, specify a prefix of ldaps:// instead of ldap://. Also, the default port for SSL-enabled LDAP connections is 636 instead of 389.

Secure LDAP connections through TLS:

TLS, the successor to the SSL protocol, is supported by most modern LDAP servers. Unlike SSL connections, TLS connections can be made on the same server port as non-TLS connections. To secure all connections using TLS, specify the following flags as startup options to the impalad daemon:

• --ldap_tls tells Impala to start a TLS connection to the LDAP server, and to fail authentication if it cannot be done.
• --ldap_ca_certificate="/path/to/certificate/pem" specifies the location of the certificate in standard .PEM format. Store this certificate on the local filesystem, in a location that only the impala user and other trusted users can read.

LDAP authentication for impala-shell interpreter:

To connect to Impala using LDAP authentication, you specify command-line options to the impala-shell command interpreter and enter the password when prompted:

• -l enables LDAP authentication.
• -u sets the user. Per Active Directory, the user is the short user name, not the full LDAP distinguished name. If your LDAP settings include a search base, use the --ldap_bind_pattern on the impalad daemon to translate the short user name from impala-shell automatically to the fully qualified name.
• impala-shell automatically prompts for the password.

For the full list of available impala-shell options, see impala-shell Command-Line Options.

LDAP authentication for JDBC applications: See Configuring Impala to Work with JDBC for the format to use with the JDBC connection string for servers using LDAP authentication.

Restrictions:

The LDAP support is preliminary. It currently has only been tested against Active Directory.