HI Larry,
So you are saying redirect of Kerberos/SPNEgo Principle will not work
specifically for use cae like distcp etc as it need to connect to Datanode.
Our use case is: We have secured cluter in our environment. We like to have a
gateway using knox so that customers can use these gateway to easily access
data fire jobs if require distcp also. As you are saying distcp scenarios won't
work. Atleast to start with we like to have minimum usecases to work so that
customers can intract our clusters in secured zone.
We are building POC with KNOX gateway. So after initial setup we are just
trying liststatus etc. We are planning to make use of this infrastructure with
all general usecases as long is not limited by any case.
We configured with plain LDAP username/password authentication but that is not
feasible for our environment. All our customers interact with kerbrose keytab
as all of them using batch account for various projects.
So i like to review my gateway-site.xml and hera.xml( topology) file to make
sure i am not missing any thing and why the SPNego delegation not happening
etc. we could do httpfs access
KNOXSERVER ----> httpfs process --> NN ( NN and httpfs running in same box )
from Knoxserver i can do httpfs access with out issues.curl -i -vvv
--negotiate -u :
"http://hera-hdfs-corp.test.com:14000/webhdfs/v1/hbase/?op=liststatus";
But when i access via Knox it fails as error pasted in my initial
mail:/usr/bin/curl -ik --negotiate -u : -X GET
'https://hera-zk-3.vip.test.com:8443/gateway/hera/webhdfs/v1/?op=LISTSTATUS'
Attached my configs: \Rajesh
On Monday, 14 December 2015 7:39 PM, larry mccay <[email protected]>
wrote:
Also, another clarifying thing about #3 is that it may not be an issue for
curl users as much as for existing hadoop clients that don't expect to need to
do kerberos on the second hop. So, curl or custom clients can probably handle
the redirect back through Knox again with kerberos but if you try and use
distcp or something like that it will not work.
On Mon, Dec 14, 2015 at 8:50 AM, larry mccay <[email protected]> wrote:
Also, starting with #2 - in my previous email - is probably best to ensure that
Knox is working with the kerberized cluster before introducing the hadoop auth
provider for end users. Removing that variable will make it easier to narrow
down the issue/s.
On Mon, Dec 14, 2015 at 8:44 AM, larry mccay <[email protected]> wrote:
Hi Rajesh -
A couple things...
1. Can you provide your hera.xml topology file - please scrub it of any
sensitive info like hostnames, secrets/passwords, etc?2. Have you been able to
access the same with HTTP Basic Auth against LDAP rather than trying to use the
hadoop auth module?3. There is an issue for the hadoop auth module use with
Knox that does not allow the redirect to datanodes to work due to Knox
requiring SPNEGO authentication on the redirect as well - so this may not
provide you with the access that you expect. Things like LISTSTATUS will work
because there is no redirect to datanodes.
#2 above is what I would really like to drill into a bit more. I want to make
sure that it is clear that in this type of scenario, Knox authenticated to the
secured cluster via kerberos/SPNEGO even though the end user does not. This
allows for LDAP based authentication, or whatever provider you like, to
authenticate the end user and Hadoop is configured to trust Knox to interact on
behalf of the end users. As long as Knox authenticates via kerberos, the hadoop
cluster knows that it can trust the username provided by Knox as the end user.
This is generally the approach used in secure cluster access through Knox.
I would be interested in understanding your usecase better where kerberos is
required for the end user - if this is indeed what is desired.
Thanks,
--larry
On Mon, Dec 14, 2015 at 1:58 AM, Rajesh Chandramohan <[email protected]>
wrote:
Hi ,
We were trying with knox gateway to access hadoop cluster which is
secured(kerborized). But Using Kerberos authentication we couldn’t access the
cluster. Same kerberos key we could access the data using httpFs. Can anybody
Help-us for right configuration for Knox with kerberos.
====-sh-4.1$ /usr/bin/curl -ik --negotiate -u : -X GET
'https://hera-phx-zk-3.vip.ebay.com:8443/gateway/hera/webhdfs/v1/?op=LISTSTATUS'HTTP/1.1
401 Authentication requiredWWW-Authenticate: NegotiateSet-Cookie:
hadoop.auth=; Path=/export/home/b_knox/knox/conf; Domain=ebay.com; Expires=Thu,
01-Jan-1970 00:00:00 GMT; Secure; HttpOnlyContent-Type:
text/html;charset=ISO-8859-1Cache-Control:
must-revalidate,no-cache,no-storeContent-Length: 1417Server:
Jetty(8.1.14.v20131031)
HTTP/1.1 500 Server ErrorSet-Cookie:
hadoop.auth=u=b_knox&[email protected]&t=kerberos&e=1449829226535&s=yuiBjLQqkWagz2ISmzQGmRqrXjE=;
Path=/export/home/b_knox/knox/conf; Domain=ebay.com; Expires=Fri, 11-Dec-2015
10:20:26 GMT; Secure; HttpOnlyContent-Type:
text/html;charset=ISO-8859-1Cache-Control:
must-revalidate,no-cache,no-storeContent-Length: 1395Server:
Jetty(8.1.14.v20131031)
<html><head><meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1"/><title>Error 500 Server Error</title></head><body><h2>HTTP
ERROR 500</h2><p>Problem accessing /gateway/hera/webhdfs/v1/. Reason:<pre>
Server Error</pre></p><hr /><i><small>Powered by Jetty://</small></i><br/><br/>
----- httpFs----Worked with same kerberos-----sh-4.1$ curl -i -vvv --negotiate
-u : "http://hera-phx-nn-2.vip.ebay.com:14000/webhdfs/v1/hbase/?op=liststatus";
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0
> zlib/1.2.3 libidn/1.18 libssh2/1.2.2> Host: hera-phx-nn-2.vip.ebay.com:14000>
> Accept: */*>< HTTP/1.1 200 OKHTTP/1.1 200 OK< Server:
> Apache-Coyote/1.1Server: Apache-Coyote/1.1< Set-Cookie:
> hadoop.auth=u=b_knox&[email protected]&t=composite&e=1449863459356&s=df8H1d7PwSqHVC7T62+yXNYq7i4=;
> Path=/; Expires=Fri, 11-Dec-2015 19:50:59 GMT; HttpOnlySet-Cookie:
> hadoop.auth=u=b_knox&[email protected]&t=composite&e=1449863459356&s=df8H1d7PwSqHVC7T62+yXNYq7i4=;
> Path=/; Expires=Fri, 11-Dec-2015 19:50:59 GMT; HttpOnly< Content-Type:
> application/jsonContent-Type: application/json< Transfer-Encoding:
> chunkedTransfer-Encoding: chunked< Date: Fri, 11 Dec 2015 09:51:03 GMTDate:
> Fri, 11 Dec 2015 09:51:03 GMT
< \Rajesh
<?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.
-->
<configuration>
<property>
<name>gateway.port</name>
<value>8443</value>
<description>The HTTP port for the Gateway.</description>
</property>
<property>
<name>gateway.path</name>
<value>gateway</value>
<description>The default context path for the gateway.</description>
</property>
<property>
<name>gateway.gateway.conf.dir</name>
<value>deployments</value>
<description>The directory within GATEWAY_HOME that contains gateway topology files and deployments.</description>
</property>
<property>
<name>gateway.hadoop.kerberos.secured</name>
<value>true</value>
<description>Boolean flag indicating whether the Hadoop cluster protected by Gateway is secured with Kerberos</description>
</property>
<property>
<name>java.security.krb5.conf</name>
<!-- <value>/export/home/b_knox/knox/conf/krb5.conf</value> -->
<value>/etc/krb5.conf</value>
<description>Absolute path to krb5.conf file</description>
</property>
<property>
<name>java.security.auth.login.config</name>
<value>/export/home/b_knox/knox/conf/krb5JAASLogin.conf</value>
<description>Absolute path to JASS login config file</description>
</property>
<property>
<name>sun.security.krb5.debug</name>
<value>true</value>
<description>Boolean flag indicating whether to enable debug messages for krb5 authentication</description>
</property>
</configuration>
<?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.
-->
<topology>
<gateway>
<provider>
<role>authentication</role>
<name>HadoopAuth</name>
<enabled>true</enabled>
<param>
<name>config.prefix</name>
<value>hadoop.auth.config</value>
</param>
<param>
<name>hadoop.auth.config.signature.secret</name>
<value>XXXXXXX</value>
</param>
<param>
<name>hadoop.auth.config.type</name>
<value>kerberos</value>
</param>
<param>
<name>hadoop.auth.config.simple.anonymous.allowed</name>
<value>false</value>
</param>
<param>
<name>hadoop.auth.config.token.validity</name>
<value>1800</value>
</param>
<param>
<name>hadoop.auth.config.cookie.domain</name>
<value>test.com</value>
</param>
<param>
<name>hadoop.auth.config.cookie.path</name>
<value>/export/home/b_knox/knox/conf</value>
</param>
<param>
<name>hadoop.auth.config.kerberos.principal</name>
<value>HTTP/[email protected]</value>
</param>
<param>
<name>hadoop.auth.config.kerberos.keytab</name>
<value>/export/home/b_knox/.keytabs/apd/http-zk3-apd.keytab</value>
</param>
<param>
<name>hadoop.auth.config.kerberos.name.rules</name>
<value>
RULE:[1:$1]
RULE:[2:$1]
DEFAULT
</value>
</param>
</provider>
<!--
-->
<provider>
<role>identity-assertion</role>
<name>Default</name>
<enabled>true</enabled>
</provider>
<!--
Defines rules for mapping host names internal to a Hadoop cluster to externally accessible host names.
For example, a hadoop service running in AWS may return a response that includes URLs containing the
some AWS internal host name. If the client needs to make a subsequent request to the host identified
in those URLs they need to be mapped to external host names that the client Knox can use to connect.
If the external hostname and internal host names are same turn of this provider by setting the value of
enabled parameter as false.
The name parameter specifies the external host names in a comma separated list.
The value parameter specifies corresponding internal host names in a comma separated list.
Note that when you are using Sandbox, the external hostname needs to be localhost, as seen in out
of box sandbox.xml. This is because Sandbox uses port mapping to allow clients to connect to the
Hadoop services using localhost. In real clusters, external host names would almost never be localhost.
-->
<provider>
<role>hostmap</role>
<name>static</name>
<enabled>true</enabled>
<param><name>localhost</name><value>sandbox,sandbox.hortonworks.com</value></param>
</provider>
</gateway>
<service>
<role>NAMENODE</role>
<url>hdfs://hera-nn-1.vip.test.com:8020</url>
</service>
<service>
<role>JOBTRACKER</role>
<url>rpc://hera-jt.vip.test.com:8032</url>
</service>
<service>
<role>WEBHDFS</role>
<url>http://hera-nn-2.vip.test.com:14000/webhdfs</url>
</service>
<!--
<service>
<role>WEBHCAT</role>
<url>http://localhost:50111/templeton</url>
</service>
<service>
<role>OOZIE</role>
<url>http://localhost:11000/oozie</url>
</service>
<service>
<role>WEBHBASE</role>
<url>http://localhost:60080</url>
</service>
<service>
<role>HIVE</role>
<url>http://localhost:10001/cliservice</url>
</service>
<service>
<role>RESOURCEMANAGER</role>
<url>http://localhost:8088/ws</url>
</service>
-->
</topology>
