<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>question Re: Connection between clusters with and without Kerberos in Archives of Support Questions (Read Only)</title>
    <link>https://community.cloudera.com/t5/Archives-of-Support-Questions/Connection-between-clusters-with-and-without-Kerberos/m-p/134402#M31581</link>
    <description>&lt;P&gt;Hello &lt;A rel="user" href="https://community.cloudera.com/users/11059/tsantiago.html" nodeid="11059"&gt;@Thiago&lt;/A&gt;.  It is possible to achieve communication across secured and unsecured clusters.  A common use case for this is using DistCp for transfer of data between clusters.&lt;/P&gt;&lt;P&gt;As mentioned in other answers, the configuration property ipc.client.fallback-to-simple-auth-allowed=true tells a secured client that it may enter a fallback unsecured mode when the unsecured server side fails to satisfy authentication.  However, I recommend not setting this in core-site.xml, and instead setting it on the command line invocation specifically for the DistCp command that needs to communicate with the unsecured cluster. Setting it in core-site.xml means that all RPC connections for any application are eligible for fallback to simple authentication. This potentially expands the attack surface for man-in-the-middle attacks.&lt;/P&gt;&lt;P&gt;Here is an example of overriding the setting on the command line while running DistCp:&lt;/P&gt;&lt;PRE&gt;hadoop distcp -D ipc.client.fallback-to-simple-auth-allowed=true hdfs://nn1:8020/foo/bar hdfs://nn2:8020/bar/foo&lt;/PRE&gt;&lt;P&gt;The command must be run while logged into the secured cluster, not the unsecured cluster.&lt;/P&gt;&lt;P&gt;This is adapted from one of my prior answers:&lt;/P&gt;&lt;P&gt;&lt;A href="https://community.hortonworks.com/questions/294/running-distcp-between-two-cluster-one-kerberized.html" target="_blank"&gt;https://community.hortonworks.com/questions/294/running-distcp-between-two-cluster-one-kerberized.html&lt;/A&gt;&lt;/P&gt;</description>
    <pubDate>Sun, 12 Jun 2016 03:46:11 GMT</pubDate>
    <dc:creator>cnauroth</dc:creator>
    <dc:date>2016-06-12T03:46:11Z</dc:date>
    <item>
      <title>Connection between clusters with and without Kerberos</title>
      <link>https://community.cloudera.com/t5/Archives-of-Support-Questions/Connection-between-clusters-with-and-without-Kerberos/m-p/134400#M31579</link>
      <description>&lt;P&gt;Hi there! how are you? &lt;span class="lia-unicode-emoji" title=":grinning_face_with_big_eyes:"&gt;😃&lt;/span&gt;&lt;/P&gt;&lt;P&gt;We have a HDP 2.2 cluster (without Kerberos) already on Production, and we are planning to build another HPD 2.4 cluster (with Kerberos) on the side of the first one. &lt;/P&gt;&lt;P&gt; 
So, cutting to the chase, my doubt is: Are we going to have some troubles on the attempting to connect to a kerberos enabled cluster? &lt;/P&gt;&lt;P&gt;Are there limitations on the communication between clusters? I mean, will a cluster be able to connect to the cluster for read/write operations, without getting kerberos errors. &lt;/P&gt;&lt;P&gt;
As far as I know, this is not a supported configuration but I am looking for someone that has experience configuring this solution. &lt;/P&gt;&lt;P&gt;Thanks in advance. &lt;/P&gt;&lt;P&gt;Thiago.&lt;/P&gt;</description>
      <pubDate>Fri, 16 Sep 2022 10:24:34 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Archives-of-Support-Questions/Connection-between-clusters-with-and-without-Kerberos/m-p/134400#M31579</guid>
      <dc:creator>ThiagoSantiago</dc:creator>
      <dc:date>2022-09-16T10:24:34Z</dc:date>
    </item>
    <item>
      <title>Re: Connection between clusters with and without Kerberos</title>
      <link>https://community.cloudera.com/t5/Archives-of-Support-Questions/Connection-between-clusters-with-and-without-Kerberos/m-p/134401#M31580</link>
      <description>&lt;A rel="user" href="https://community.cloudera.com/users/11059/tsantiago.html" nodeid="11059"&gt;@Thiago&lt;/A&gt;&lt;P&gt;If you are using DistCp and WebHDFS to copy data between a secure cluster and an nonsecure cluster by doing the following:
&lt;/P&gt;&lt;P&gt;&lt;A href="https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.2/bk_Sys_Admin_Guides/content/ref-c8ffaa14-eaf8-48a6-9791-307283d5d29d.1.html" target="_blank"&gt;https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.2/bk_Sys_Admin_Guides/content/ref-c8ffaa14-eaf8-48a6-9791-307283d5d29d.1.html&lt;/A&gt;&lt;/P&gt;&lt;OL&gt;
&lt;LI&gt;Set ipc.client.fallback-to-simple-auth-allowed to true in core-site.xml &lt;EM&gt;on the secure cluster side&lt;/EM&gt;:&lt;PRE&gt;&amp;lt;property&amp;gt; 
  &amp;lt;name&amp;gt;ipc.client.fallback-to-simple-auth-allowed&amp;lt;/name&amp;gt;
  &amp;lt;value&amp;gt;true&amp;lt;/value&amp;gt; 
&amp;lt;/property&amp;gt;&lt;/PRE&gt;
&lt;/LI&gt;
&lt;LI&gt;Use below commands &lt;EM&gt;from the secure cluster side.&lt;/EM&gt;&lt;PRE&gt;distcp webhdfs://nonsecure-cluster webhdfs://secure-cluster 
distcp webhdfs://secure-cluster webhdfs://nonsecure-cluster 
&lt;/PRE&gt;&lt;/LI&gt;&lt;/OL&gt;</description>
      <pubDate>Sun, 12 Jun 2016 00:04:54 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Archives-of-Support-Questions/Connection-between-clusters-with-and-without-Kerberos/m-p/134401#M31580</guid>
      <dc:creator>jyadav</dc:creator>
      <dc:date>2016-06-12T00:04:54Z</dc:date>
    </item>
    <item>
      <title>Re: Connection between clusters with and without Kerberos</title>
      <link>https://community.cloudera.com/t5/Archives-of-Support-Questions/Connection-between-clusters-with-and-without-Kerberos/m-p/134402#M31581</link>
      <description>&lt;P&gt;Hello &lt;A rel="user" href="https://community.cloudera.com/users/11059/tsantiago.html" nodeid="11059"&gt;@Thiago&lt;/A&gt;.  It is possible to achieve communication across secured and unsecured clusters.  A common use case for this is using DistCp for transfer of data between clusters.&lt;/P&gt;&lt;P&gt;As mentioned in other answers, the configuration property ipc.client.fallback-to-simple-auth-allowed=true tells a secured client that it may enter a fallback unsecured mode when the unsecured server side fails to satisfy authentication.  However, I recommend not setting this in core-site.xml, and instead setting it on the command line invocation specifically for the DistCp command that needs to communicate with the unsecured cluster. Setting it in core-site.xml means that all RPC connections for any application are eligible for fallback to simple authentication. This potentially expands the attack surface for man-in-the-middle attacks.&lt;/P&gt;&lt;P&gt;Here is an example of overriding the setting on the command line while running DistCp:&lt;/P&gt;&lt;PRE&gt;hadoop distcp -D ipc.client.fallback-to-simple-auth-allowed=true hdfs://nn1:8020/foo/bar hdfs://nn2:8020/bar/foo&lt;/PRE&gt;&lt;P&gt;The command must be run while logged into the secured cluster, not the unsecured cluster.&lt;/P&gt;&lt;P&gt;This is adapted from one of my prior answers:&lt;/P&gt;&lt;P&gt;&lt;A href="https://community.hortonworks.com/questions/294/running-distcp-between-two-cluster-one-kerberized.html" target="_blank"&gt;https://community.hortonworks.com/questions/294/running-distcp-between-two-cluster-one-kerberized.html&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Sun, 12 Jun 2016 03:46:11 GMT</pubDate>
      <guid>https://community.cloudera.com/t5/Archives-of-Support-Questions/Connection-between-clusters-with-and-without-Kerberos/m-p/134402#M31581</guid>
      <dc:creator>cnauroth</dc:creator>
      <dc:date>2016-06-12T03:46:11Z</dc:date>
    </item>
  </channel>
</rss>

