mirror of
https://github.com/apache/impala.git
synced 2025-12-19 09:58:28 -05:00
5670f96b82
Change-Id: Ia665e3f230f218d8bbf998dfd1ae21338c21b36e Reviewed-on: http://gerrit.cloudera.org:8080/12908 Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com> Reviewed-by: Alex Rodoni <arodoni@cloudera.com>
398 lines
14 KiB
XML
398 lines
14 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!--
|
|
Licensed to the Apache Software Foundation (ASF) under one
|
|
or more contributor license agreements. See the NOTICE file
|
|
distributed with this work for additional information
|
|
regarding copyright ownership. The ASF licenses this file
|
|
to you under the Apache License, Version 2.0 (the
|
|
"License"); you may not use this file except in compliance
|
|
with the License. You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing,
|
|
software distributed under the License is distributed on an
|
|
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
|
KIND, either express or implied. See the License for the
|
|
specific language governing permissions and limitations
|
|
under the License.
|
|
-->
|
|
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
|
|
<concept id="kerberos">
|
|
|
|
<title>Enabling Kerberos Authentication for Impala</title>
|
|
|
|
<prolog>
|
|
<metadata>
|
|
<data name="Category" value="Security"/>
|
|
<data name="Category" value="Kerberos"/>
|
|
<data name="Category" value="Authentication"/>
|
|
<data name="Category" value="Impala"/>
|
|
<data name="Category" value="Configuring"/>
|
|
<data name="Category" value="Starting and Stopping"/>
|
|
<data name="Category" value="Administrators"/>
|
|
</metadata>
|
|
</prolog>
|
|
|
|
<conbody>
|
|
|
|
<p>
|
|
Impala supports an enterprise-grade authentication system called Kerberos. Kerberos
|
|
provides strong security benefits including capabilities that render intercepted
|
|
authentication packets unusable by an attacker. It virtually eliminates the threat of
|
|
impersonation by never sending a user's credentials in cleartext over the network. For
|
|
more information on Kerberos, visit the
|
|
<xref href="https://web.mit.edu/kerberos/" scope="external" format="html">MIT Kerberos
|
|
website</xref>.
|
|
</p>
|
|
|
|
<p>
|
|
The rest of this topic assumes you have a working <xref keyref="mit_install_kdc"/> set up.
|
|
To enable Kerberos, you first create a Kerberos principal for each host running
|
|
<cmdname>impalad</cmdname> or <cmdname>statestored</cmdname>.
|
|
</p>
|
|
|
|
<note conref="../shared/impala_common.xml#common/authentication_vs_authorization"/>
|
|
|
|
<p>
|
|
An alternative form of authentication you can use is LDAP, described in
|
|
<xref href="impala_ldap.xml#ldap"/>.
|
|
</p>
|
|
|
|
<p outputclass="toc inpage"/>
|
|
|
|
</conbody>
|
|
|
|
<concept id="kerberos_prereqs">
|
|
|
|
<title>Requirements for Using Impala with Kerberos</title>
|
|
|
|
<prolog>
|
|
<metadata>
|
|
<data name="Category" value="Requirements"/>
|
|
<data name="Category" value="Planning"/>
|
|
</metadata>
|
|
</prolog>
|
|
|
|
<conbody>
|
|
|
|
<p conref="../shared/impala_common.xml#common/rhel5_kerberos"/>
|
|
|
|
<note type="important">
|
|
<p>
|
|
If you plan to use Impala in your cluster, you must configure your KDC to allow
|
|
tickets to be renewed, and you must configure <filepath>krb5.conf</filepath> to
|
|
request renewable tickets. Typically, you can do this by adding the
|
|
<codeph>max_renewable_life</codeph> setting to your realm in
|
|
<filepath>kdc.conf</filepath>, and by adding the <filepath>renew_lifetime</filepath>
|
|
parameter to the <filepath>libdefaults</filepath> section of
|
|
<filepath>krb5.conf</filepath>. For more information about renewable tickets, see the
|
|
<xref href="http://web.mit.edu/Kerberos/krb5-1.8/" scope="external" format="html">
|
|
Kerberos documentation</xref>.
|
|
</p>
|
|
</note>
|
|
|
|
<p>
|
|
Start all <cmdname>impalad</cmdname> and <cmdname>statestored</cmdname> daemons with the
|
|
<codeph>‑‑principal</codeph> and <codeph>‑‑keytab-file</codeph>
|
|
flags set to the principal and full path name of the <codeph>keytab</codeph> file
|
|
containing the credentials for the principal.
|
|
</p>
|
|
|
|
<p>
|
|
To enable Kerberos in the Impala shell, start the <cmdname>impala-shell</cmdname>
|
|
command using the <codeph>-k</codeph> flag.
|
|
</p>
|
|
|
|
<p>
|
|
To enable Impala to work with Kerberos security on your Hadoop cluster, make sure you
|
|
perform the installation and configuration steps in
|
|
<xref keyref="upstream_hadoop_authentication"/>. Note that when Kerberos security is
|
|
enabled in Impala, a web browser that supports Kerberos HTTP SPNEGO is required to
|
|
access the Impala web console (for example, Firefox, Internet Explorer, or Chrome).
|
|
</p>
|
|
|
|
<p>
|
|
If the NameNode, Secondary NameNode, DataNode, JobTracker, TaskTrackers,
|
|
ResourceManager, NodeManagers, HttpFS, Oozie, Impala, or Impala statestore services are
|
|
configured to use Kerberos HTTP SPNEGO authentication, and two or more of these services
|
|
are running on the same host, then all of the running services must use the same HTTP
|
|
principal and keytab file used for their HTTP endpoints.
|
|
</p>
|
|
|
|
</conbody>
|
|
|
|
</concept>
|
|
|
|
<concept id="kerberos_config">
|
|
|
|
<title>Configuring Impala to Support Kerberos Security</title>
|
|
|
|
<prolog>
|
|
<metadata>
|
|
<data name="Category" value="Configuring"/>
|
|
</metadata>
|
|
</prolog>
|
|
|
|
<conbody>
|
|
|
|
<p>
|
|
Enabling Kerberos authentication for Impala involves steps that can be summarized as
|
|
follows:
|
|
</p>
|
|
|
|
<ul>
|
|
<li>
|
|
Creating service principals for Impala and the HTTP service. Principal names take the
|
|
form:
|
|
<codeph><varname>serviceName</varname>/<varname>fully.qualified.domain.name</varname>@<varname>KERBEROS.REALM</varname></codeph>.
|
|
<p conref="../shared/impala_common.xml#common/user_kerberized"/>
|
|
</li>
|
|
|
|
<li>
|
|
Creating, merging, and distributing key tab files for these principals.
|
|
</li>
|
|
|
|
<li>
|
|
Editing <codeph>/etc/default/impala</codeph> to accommodate Kerberos authentication.
|
|
</li>
|
|
</ul>
|
|
|
|
</conbody>
|
|
|
|
<concept id="kerberos_setup">
|
|
|
|
<title>Enabling Kerberos for Impala</title>
|
|
|
|
<conbody>
|
|
|
|
<!--
|
|
<p>
|
|
<b>To enable Kerberos for Impala:</b>
|
|
</p>
|
|
-->
|
|
|
|
<ol>
|
|
<li>
|
|
Create an Impala service principal, specifying the name of the OS user that the
|
|
Impala daemons run under, the fully qualified domain name of each node running
|
|
<cmdname>impalad</cmdname>, and the realm name. For example:
|
|
<codeblock>$ kadmin
|
|
kadmin: addprinc -requires_preauth -randkey impala/impala_host.example.com@TEST.EXAMPLE.COM</codeblock>
|
|
</li>
|
|
|
|
<li>
|
|
Create an HTTP service principal. For example:
|
|
<codeblock>kadmin: addprinc -randkey HTTP/impala_host.example.com@TEST.EXAMPLE.COM</codeblock>
|
|
<note>
|
|
The <codeph>HTTP</codeph> component of the service principal must be uppercase as
|
|
shown in the preceding example.
|
|
</note>
|
|
</li>
|
|
|
|
<li>
|
|
Create <codeph>keytab</codeph> files with both principals. For example:
|
|
<codeblock>kadmin: xst -k impala.keytab impala/impala_host.example.com
|
|
kadmin: xst -k http.keytab HTTP/impala_host.example.com
|
|
kadmin: quit</codeblock>
|
|
</li>
|
|
|
|
<li>
|
|
Use <codeph>ktutil</codeph> to read the contents of the two keytab files and then
|
|
write those contents to a new file. For example:
|
|
<codeblock>$ ktutil
|
|
ktutil: rkt impala.keytab
|
|
ktutil: rkt http.keytab
|
|
ktutil: wkt impala-http.keytab
|
|
ktutil: quit</codeblock>
|
|
</li>
|
|
|
|
<li>
|
|
(Optional) Test that credentials in the merged keytab file are valid, and that the
|
|
<q>renew until</q> date is in the future. For example:
|
|
<codeblock>$ klist -e -k -t impala-http.keytab</codeblock>
|
|
</li>
|
|
|
|
<li>
|
|
Copy the <filepath>impala-http.keytab</filepath> file to the Impala configuration
|
|
directory. Change the permissions to be only read for the file owner and change the
|
|
file owner to the <codeph>impala</codeph> user. By default, the Impala user and
|
|
group are both named <codeph>impala</codeph>. For example:
|
|
<codeblock>$ cp impala-http.keytab /etc/impala/conf
|
|
$ cd /etc/impala/conf
|
|
$ chmod 400 impala-http.keytab
|
|
$ chown impala:impala impala-http.keytab</codeblock>
|
|
</li>
|
|
|
|
<li>
|
|
Add Kerberos options to the Impala defaults file,
|
|
<filepath>/etc/default/impala</filepath>. Add the options for both the
|
|
<cmdname>impalad</cmdname> and <cmdname>statestored</cmdname> daemons, using the
|
|
<codeph>IMPALA_SERVER_ARGS</codeph> and <codeph>IMPALA_STATE_STORE_ARGS</codeph>
|
|
variables. For example, you might add:
|
|
<!-- Found these in a discussion post somewhere but not applicable as Impala startup options.
|
|
-kerberos_ticket_life=36000
|
|
-maxrenewlife 7days
|
|
-->
|
|
<codeblock>-kerberos_reinit_interval=60
|
|
-principal=impala_1/impala_host.example.com@TEST.EXAMPLE.COM
|
|
-keytab_file=<varname>/path/to/impala.keytab</varname></codeblock>
|
|
<p>
|
|
For more information on changing the Impala defaults specified in
|
|
<filepath>/etc/default/impala</filepath>, see
|
|
<xref href="impala_config_options.xml#config_options">Modifying Impala Startup
|
|
Options</xref>.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<note>
|
|
Restart <cmdname>impalad</cmdname> and <cmdname>statestored</cmdname> for these
|
|
configuration changes to take effect.
|
|
</note>
|
|
|
|
</conbody>
|
|
|
|
</concept>
|
|
|
|
</concept>
|
|
|
|
<concept id="kerberos_proxy">
|
|
|
|
<title>Enabling Kerberos for Impala with a Proxy Server</title>
|
|
|
|
<conbody>
|
|
|
|
<p>
|
|
A common configuration for Impala with High Availability is to use a proxy server to
|
|
submit requests to the actual <cmdname>impalad</cmdname> 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 <q>coordinator node</q> for each query is spread across multiple
|
|
hosts.
|
|
</p>
|
|
|
|
<p>
|
|
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
|
|
<xref href="impala_proxy.xml#proxy"/>.
|
|
</p>
|
|
|
|
</conbody>
|
|
|
|
</concept>
|
|
|
|
<concept id="spnego">
|
|
|
|
<title>Using a Web Browser to Access a URL Protected by Kerberos HTTP SPNEGO</title>
|
|
|
|
<conbody>
|
|
|
|
<p>
|
|
Your web browser must support Kerberos HTTP SPNEGO. For example, Chrome, Firefox, or
|
|
Internet Explorer.
|
|
</p>
|
|
|
|
<p>
|
|
<b>To configure Firefox to access a URL protected by Kerberos HTTP SPNEGO:</b>
|
|
</p>
|
|
|
|
<ol>
|
|
<li>
|
|
Open the advanced settings Firefox configuration page by loading the
|
|
<codeph>about:config</codeph> page.
|
|
</li>
|
|
|
|
<li>
|
|
Use the <b>Filter</b> text box to find
|
|
<codeph>network.negotiate-auth.trusted-uris</codeph>.
|
|
</li>
|
|
|
|
<li>
|
|
Double-click the <codeph>network.negotiate-auth.trusted-uris</codeph> preference and
|
|
enter the hostname or the domain of the web server that is protected by Kerberos HTTP
|
|
SPNEGO. Separate multiple domains and hostnames with a comma.
|
|
</li>
|
|
|
|
<li>
|
|
Click <b>OK</b>.
|
|
</li>
|
|
</ol>
|
|
|
|
</conbody>
|
|
|
|
</concept>
|
|
|
|
<concept id="kerberos_delegation">
|
|
|
|
<title>Enabling Impala Delegation for Kerberos Users</title>
|
|
|
|
<conbody>
|
|
|
|
<p>
|
|
See <xref href="impala_delegation.xml#delegation"/> for details about the delegation
|
|
feature that lets certain users submit queries using the credentials of other users.
|
|
</p>
|
|
|
|
</conbody>
|
|
|
|
</concept>
|
|
|
|
<concept id="ssl_jdbc_odbc">
|
|
|
|
<title>Using TLS/SSL with Business Intelligence Tools</title>
|
|
|
|
<conbody>
|
|
|
|
<p>
|
|
You can use Kerberos authentication, TLS/SSL encryption, or both to secure connections
|
|
from JDBC and ODBC applications to Impala. See
|
|
<xref href="impala_jdbc.xml#impala_jdbc"/> and
|
|
<xref href="impala_odbc.xml#impala_odbc"/> for details.
|
|
</p>
|
|
|
|
<p conref="../shared/impala_common.xml#common/hive_jdbc_ssl_kerberos_caveat"/>
|
|
|
|
</conbody>
|
|
|
|
</concept>
|
|
|
|
<concept id="whitelisting_internal_apis">
|
|
|
|
<title>Enabling Access to Internal Impala APIs for Kerberos Users</title>
|
|
|
|
<conbody>
|
|
|
|
<!-- Reusing (most of) the text from the New Features bullet here. Turn into a conref in both places. -->
|
|
|
|
<p rev="IMPALA-3095">
|
|
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 <codeph>impala</codeph> and
|
|
<codeph>hdfs</codeph> users are the only ones authorized for this kind of access. Any
|
|
users not explicitly authorized through the
|
|
<codeph>internal_principals_whitelist</codeph> 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.
|
|
</p>
|
|
|
|
</conbody>
|
|
|
|
</concept>
|
|
|
|
<concept id="auth_to_local" rev="IMPALA-2660">
|
|
|
|
<title>Mapping Kerberos Principals to Short Names for Impala</title>
|
|
|
|
<conbody>
|
|
|
|
<p conref="../shared/impala_common.xml#common/auth_to_local_instructions"/>
|
|
|
|
</conbody>
|
|
|
|
</concept>
|
|
|
|
</concept>
|