hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Joseph Evans (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-2858) MRv2 WebApp Security
Date Thu, 13 Oct 2011 17:15:12 GMT

    [ 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
> 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


View raw message