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

Robert Joseph Evans commented on MAPREDUCE-2858:
------------------------------------------------

I could try to draw up a MSC or something for you, and yes, it is looking ever 
more complex, and also potentially very brittle.  The issue with just 
configuring a filter is that there is no guarantee that the AM will honor that, 
or if the AM is not written in Java there is no way that it could support that 
(Yes I know because of how the RPC currently works it has to be in Java, but 
that might change in the future).  There is also the possibility that the AM 
could return JavaScript that will pull out the cookies itself and send them off 
somewhere.  So the proxy has to verify that what is being returned by the 
server is acceptable.



I personally think that we need to move all of the web interfaces on to 
separate stateless servers that can then communicate with the AM/RM/NM through 
the already existing RPC.  We would have to buff up the RPC to have it return 
the full set of data that the UI or web servers need.  It would also be cool if 
we could add in some sort of caching to the RPC, so that we don't have to hit 
the RM every time someone loads up the Applications page.

The Pros for this:
  # Less security issues.  We are running trusted code on a trusted server as a 
trusted user.
  # All data on the UI is accessible programatically. (No need to ever scrape a 
web page)
  # MAPREDUCE-3174 goes away and we can get a more unified user experience 
(Without proxies of any sort).

The Cons for this:
  # Users cannot change the web interface themselves (But since most M/R jobs 
only run for a couple of mins I don't think it is that critical)
  # App Masters that are not trusted do not get a web interface.
  # Possibly slower because we need an extra hop to get to the data (but if we 
are going through a proxy it is not really that different)
  
                
> MRv2 WebApp Security
> --------------------
>
>                 Key: MAPREDUCE-2858
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-2858
>             Project: Hadoop Map/Reduce
>          Issue Type: Sub-task
>          Components: applicationmaster, mrv2, security
>    Affects Versions: 0.23.0
>            Reporter: Luke Lu
>            Assignee: Luke Lu
>            Priority: Blocker
>             Fix For: 0.23.0
>
>
> In MRv2, while the system servers (ResourceManager (RM), NodeManager (NM) and 
> NameNode (NN)) run as "trusted"
> system users, the application masters (AM) run as users who submit the 
> application. While this offers great flexibility
> to run multiple version of mapreduce frameworks (including their UI) on the 
> same Hadoop cluster, it has significant
> implication for the security of webapps (Please do not discuss company 
> specific vulnerabilities here).
> Requirements:
> # Secure authentication for AM (for app/job level ACLs).
> # Webapp security should be optional via site configuration.
> # Support existing pluggable single sign on mechanisms.
> # Should not require per app/user configuration for deployment.
> # Should not require special site-wide DNS configuration for deployment.
> This the top jira for webapp security. A design doc/notes of threat-modeling 
> and counter measures will be posted on the wiki.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to