[ 
https://issues.apache.org/jira/browse/YARN-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Maron updated YARN-3068:
---------------------------------
    Description: 
When exposing a web endpoint for UI and REST, an AM is dependent on the RM as a 
proxy for incoming interactions.  The RM web proxy supports security features 
such as SSL and SPNEGO.  However, those security mechanisms are not supported 
by the AM, and supporting them directly at the AM would require some complex 
implementation details and configuration (not to mention that given the 
proxying relationship they may be considered somewhat redundant).

In order to ensure that there is a measure of security (trust) between the RM 
web proxy and the AM, the following mechanism is suggested:

- The RM will create a shared secret and propagate it to the AM during AM 
launch (e.g. it could be part of the existing credentials).
- The web proxy will leverage the shared secret to encrypt an agreed upon text 
(e.g. the container ID) and an associated expiry time (to mitigate potential 
request spoofing).
- The AM will decrypt the text leveraging the shared secret and, if successful 
and the expiry time has not been reached, proceed with the request processing 
(probably appropriate to perform these checks in the existing AmIpFilter or a 
specific trust filter).

Note that this feature is key to supporting interactions between Knox and AM 
REST resources, since those interactions depend on trusted proxy support the RM 
can provide (via its current SPNEGO and "doAs" support), allowing AM's to focus 
on performing their processing based on the established doAs identity 
(established at the RM and related to the AM via a trusted path).

  was:
When exposing a web endpoint for UI and REST, an AM is dependent on the RM as a 
proxy for incoming interactions.  The RM web proxy supports security features 
such as SSL and SPNEGO.  However, those security mechanisms are not supported 
by the AM, and supporting them directly at the AM would require some complex 
implementation details and configuration (not to mention that given the 
proxying relationship they may be considered somewhat redundant).

In order to ensure that there is a measure of security (trust) between the RM 
web proxy and the AM, the following mechanism is suggested:

- The AM will create a shared secret and propagate it to the AM during AM 
launch (e.g. it could be part of the existing credentials).
- The web proxy will leverage the shared secret to encrypt an agreed upon text 
(e.g. the container ID) and an associated expiry time (to mitigate potential 
request spoofing).
- The AM will decrypt the text leveraging the shared secret and, if successful 
and the expiry time has not been reached, proceed with the request processing 
(probably appropriate to perform these checks in the existing AmIpFilter or a 
specific trust filter).

Note that this feature is key to supporting interactions between Knox and AM 
REST resources, since those interactions depend on trusted proxy support the RM 
can provide (via its current SPNEGO and "doAs" support), allowing AM's to focus 
on performing their processing based on the established doAs identity 
(established at the RM and related to the AM via a trusted path).


> Support secure HTTP communications between RM proxy and AM web endpoint
> -----------------------------------------------------------------------
>
>                 Key: YARN-3068
>                 URL: https://issues.apache.org/jira/browse/YARN-3068
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: applications, resourcemanager
>            Reporter: Jonathan Maron
>
> When exposing a web endpoint for UI and REST, an AM is dependent on the RM as 
> a proxy for incoming interactions.  The RM web proxy supports security 
> features such as SSL and SPNEGO.  However, those security mechanisms are not 
> supported by the AM, and supporting them directly at the AM would require 
> some complex implementation details and configuration (not to mention that 
> given the proxying relationship they may be considered somewhat redundant).
> In order to ensure that there is a measure of security (trust) between the RM 
> web proxy and the AM, the following mechanism is suggested:
> - The RM will create a shared secret and propagate it to the AM during AM 
> launch (e.g. it could be part of the existing credentials).
> - The web proxy will leverage the shared secret to encrypt an agreed upon 
> text (e.g. the container ID) and an associated expiry time (to mitigate 
> potential request spoofing).
> - The AM will decrypt the text leveraging the shared secret and, if 
> successful and the expiry time has not been reached, proceed with the request 
> processing (probably appropriate to perform these checks in the existing 
> AmIpFilter or a specific trust filter).
> Note that this feature is key to supporting interactions between Knox and AM 
> REST resources, since those interactions depend on trusted proxy support the 
> RM can provide (via its current SPNEGO and "doAs" support), allowing AM's to 
> focus on performing their processing based on the established doAs identity 
> (established at the RM and related to the AM via a trusted path).



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

Reply via email to