Return-Path: X-Original-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 989C5D6BF for ; Fri, 28 Sep 2012 09:46:24 +0000 (UTC) Received: (qmail 52681 invoked by uid 500); 28 Sep 2012 09:46:20 -0000 Delivered-To: apmail-hadoop-mapreduce-user-archive@hadoop.apache.org Received: (qmail 52490 invoked by uid 500); 28 Sep 2012 09:46:19 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 52479 invoked by uid 99); 28 Sep 2012 09:46:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Sep 2012 09:46:19 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of hadoop@gmx.com designates 213.165.64.43 as permitted sender) Received: from [213.165.64.43] (HELO mailout-eu.gmx.com) (213.165.64.43) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 28 Sep 2012 09:46:11 +0000 Received: (qmail 11479 invoked by uid 0); 28 Sep 2012 09:45:33 -0000 Received: from 120.20.48.177 by rms-eu014.v300.gmx.net with HTTP Content-Type: multipart/alternative; boundary="========GMXBoundary112101348825532925585" Date: Fri, 28 Sep 2012 11:45:31 +0200 From: "Shin Chan" Message-ID: <20120928094532.112100@gmx.com> MIME-Version: 1.0 Subject: Re: Securing cluster from access To: user@hadoop.apache.org X-Authenticated: #136012697 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 X-GMX-UID: 6xQXcK5KeSEqIfgAcHwhODF+IGRvbwB5 --========GMXBoundary112101348825532925585 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hello Bertrand , Thanks for your reply. Apology if this confused you. Yes IP Tables is one of the way to go but my question is more if there is configuration within hadoop xml files to say if this user is there then only allow to see HDFS. I can see that we can do something for Map reduce jobs using acl properties ( old link for 1.x version) http://hadoop.apache.org/docs/r1.0.3/service_level_auth.html But does similar properties exists for HDFS side , where Namednode can see that this client is allowed to connect to cluster Thanks ----- Original Message ----- From: Bertrand Dechoux Sent: 09/28/12 07:34 PM To: user@hadoop.apache.org Subject: Re: Securing cluster from access What you are looking for is not related to Hadoop in the end. It is how to restrict requests in a network. 'Firewall' is a broad term. iptables can allow you to do so quickly. You drop everything and then accept only from a set of IPs. You may receive answers using this mailing list but its purpose is not really to discuss about firewall solutions and configurations. Regards Bertrand On Fri, Sep 28, 2012 at 11:23 AM, Shin Chan < hadoop@gmx.com > wrote: Hello, We have 15 node cluster and right now we dont have Kerberos implemented. But on urgent basis we want to secure the cluster. Right now anyone who know IP of Namenode can just download the Hadoop jar , configure xml files and say hadoop fs -ls / And he can see the data. How to stop this ? We have Hadoop 2.0 verison Do we have any configuration settings which we can change so that only set of users or set of IPs should be able to see the HDFS. We dont have firewall implemented yet outside cluster so that is not an option. Thanks in advance for your help -- Bertrand Dechoux Thanks and Regards , --========GMXBoundary112101348825532925585 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Be= rtrand ,
=20
=20 Thanks for your reply.
=20
=20 Apology if this confused you. Yes IP Tables is one of the way to go but my = question is more if there is configuration within hadoop xml files to say i= f this user is there then only allow to see HDFS.
=20
=20 I can see that we can do something for Map reduce jobs using acl properties= ( old link for 1.x version)
=20
=20 http://hadoop.apache.org/docs/r1.0.3/service_level_auth.html
=20

=20
=20 But does similar properties exists for HDFS side , where Namednode can see= that this client is allowed to connect to cluster
=20
=20 Thanks
=20
=20 =C2=A0

=20
=20

=20 ----- = Original Message -----

=20

=20 From: = Bertrand Dechoux

=20

=20 Sent: = 09/28/12 07:34 PM

=20

=20 To: us= er@hadoop.apache.org

=20

=20 Subjec= t: Re: Securing cluster from access

=20
=20
=20

=20 What you are looking for is not related to Hadoop in the end. It is how = to restrict requests in a network.
=20 'Firewall' is a broad term. iptables can allow you to do so quickly. You= drop everything and then accept only from a set of IPs.
=20 You may receive answers using this mailing list but its purpose is not r= eally to discuss about firewall solutions and configurations.
=20
=20 Regards
=20
=20 Bertrand
=20
=20 =C2=A0

=20
=20 On Fri, Sep 28, 2012 at 11:23 AM, Shin Chan <hadoop@gmx.com> wrote:
=20
=20 Hell= o,
=20
=20 We have 15 node cluster and right now we dont have Kerberos implemented= .
=20
=20 But on urgent basis we want to secure the cluster.
=20
=20 Right now anyone who know IP of Namenode can just download the Hadoop j= ar , configure xml files and say
=20
=20 hadoop fs -ls /
=20
=20 And he can see the data.
=20
=20 How to stop this ?
=20
=20 We have Hadoop 2.0 verison
=20
=20 Do we have any configuration settings which we can change so that only = set of users or set of IPs should be able to see the HDFS.
=20
=20 We dont have firewall implemented yet outside cluster so that is not an= option.
=20
=20 Thanks in advance for your help
=20
=20
=20
=20
=20 --
=20 Bertrand Dechoux
=20
=20

=20 =C2=A0

=20
=20
=20
=20 Thanks and Regards , --========GMXBoundary112101348825532925585--