Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 24 Apr 2017 17:43:04 +0000 (UTC)
From: "Varun Saxena (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12767001.1421111064000.34972.1493055784210@Atlassian.JIRA>
In-Reply-To: <JIRA.12767001.1421111064000@Atlassian.JIRA>
References: <JIRA.12767001.1421111064000@Atlassian.JIRA> <JIRA.12767001.1421111064702@jira-lw-us.apache.org>
Subject: [jira] [Commented] (YARN-3053) [Security] Review and implement
 authentication in ATS v.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 24 Apr 2017 17:43:09 -0000


    [ https://issues.apache.org/jira/browse/YARN-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15981565#comment-15981565 ] 

Varun Saxena commented on YARN-3053:
------------------------------------

Thanks [~rkanter] for your comments. Sorry was on leave so could not reply.

The reason I had chosen approach 1 is due to minimum amount of change required for it. We already have client and server side filter code for ATSv1 which could be reused with approach 1. Also the con I pointed out for approach 1 i.e. AM having to get the token from Allocate Response, I thought would be fine because AM would anyways have to change to publish entities to ATSv2 as the APIs' are new. 

With approach 2, we would have to still pass on the token from RM-> NM-> Collector as in the end entities would be directly published by AM to Collector. This would mean introduction of a new message in Collector Manager protocol.
The design for offline collectors is not yet decided but in future, we would probably let clients ask for token directly from Collector as well. The issue I pointed out with clash of IDs' would mean that we would have to probably differentiate between token generated by collector itself and one generated by RM. Probably differentiate on the basis of token kind. This, however doable, would mean additional changes at both the client and server side.
Moreover, we would need to also store the token in a state store even for managed apps to ensure app token is available across collector restarts.

Do you see any major issues with approach 1?

> [Security] Review and implement authentication in ATS v.2
> ---------------------------------------------------------
>
>                 Key: YARN-3053
>                 URL: https://issues.apache.org/jira/browse/YARN-3053
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Sangjin Lee
>            Assignee: Varun Saxena
>              Labels: YARN-5355, yarn-5355-merge-blocker
>         Attachments: ATSv2Authentication(draft).pdf, ATSv2Authentication.v01.pdf
>
>
> Per design in YARN-2928, we want to evaluate and review the system for security, and ensure proper security in the system.
> This includes proper authentication, token management, access control, and any other relevant security aspects.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org