Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Thu, 24 Mar 2016 16:33:25 +0000 (UTC)
From: "Robert Joseph Evans (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12946681.1457039063000.42574.1458837205815@Atlassian.JIRA>
In-Reply-To: <JIRA.12946681.1457039063000@Atlassian.JIRA>
References: <JIRA.12946681.1457039063000@Atlassian.JIRA>
 <JIRA.12946681.1457039063332@arcas>
Subject: [jira] [Commented] (YARN-4757) [Umbrella] Simplified discovery of
 services via DNS mechanisms
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/YARN-4757?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D15210=
513#comment-15210513 ]=20

Robert Joseph Evans commented on YARN-4757:
-------------------------------------------

My concern about mutual authentication is mostly around documentation and a=
sking if there is anything we can do to mitigate possible issues/attacks.  =
Instead of talking about exact attacks lets talk about a few accidents that=
 could happen, and can happen today, but are less likely because when I upd=
ate my client to use the Registry API I make different assumptions about th=
ings.

Lets say I am running a web service on YARN, and I want my customers to be =
able to get to me in through existing tools.  So I set this all up and I ha=
ve them go to http://api.bobby.yarncluster.myCompany.com:9999/ (or somethin=
g else that matches the naming convention you had, I don't remember exactly=
 and it is not relevant)  First of all I have no way to guarantee that 9999=
 is open on any node, so it is a pain but I try to launch several web serve=
rs, finally get a few to come up, the others fail and get relaunched on oth=
er nodes eventually they are all up and running, and the AM puts all of the=
m into the registry service.

Things are going well.  Customers are running using my service and everyone=
 is happy.  But then I do a rolling upgrade and I kill one container and la=
unch a new one on another box.  In the mean time some other container on th=
e box I was running on grabs port 9999 and brings up an internal web UI for=
 it.  Now many of my customers trying to hit my web service but get this ot=
her process and see 404 errors, etc.  Because DNS is eventual consistency, =
and there is a lot of caching happening, there is a race.  If the client do=
es not authenticate the server, like with https, then someone malicious cou=
ld exploit this to do all kinds of things.

I am simply saying that many people trust DNS a lot more than they should i=
n their protocols, more so when they feel that they have DNSSEC turned on i=
nternally and they are going to an internal address that they can "trust". =
 By exposing YARN through DNS it did not make it any less secure, it just m=
ade it a lot simpler for someone to deploy something that is insecure.

> [Umbrella] Simplified discovery of services via DNS mechanisms
> --------------------------------------------------------------
>
>                 Key: YARN-4757
>                 URL: https://issues.apache.org/jira/browse/YARN-4757
>             Project: Hadoop YARN
>          Issue Type: New Feature
>            Reporter: Vinod Kumar Vavilapalli
>            Assignee: Jonathan Maron
>         Attachments: YARN-4757- Simplified discovery of services via DNS =
mechanisms.pdf
>
>
> [See overview doc at YARN-4692, copying the sub-section (3.2.10.2) to tra=
ck all related efforts.]
> In addition to completing the present story of service=C2=AD-registry (YA=
RN-913), we also need to simplify the access to the registry entries. The e=
xisting read mechanisms of the YARN Service Registry are currently limited =
to a registry specific (java) API and a REST interface. In practice, this m=
akes it very difficult for wiring up existing clients and services. For e.g=
, dynamic configuration of dependent end=C2=ADpoints of a service is not ea=
sy to implement using the present registry=C2=AD-read mechanisms, *without*=
 code-changes to existing services.
> A good solution to this is to expose the registry information through a m=
ore generic and widely used discovery mechanism: DNS. Service Discovery via=
 DNS uses the well-=C2=ADknown DNS interfaces to browse the network for ser=
vices. YARN-913 in fact talked about such a DNS based mechanism but left it=
 as a future task. (Task) Having the registry information exposed via DNS s=
implifies the life of services.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)