[
https://issues.apache.org/jira/browse/MAPREDUCE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126180#comment-13126180
]
Alejandro Abdelnur commented on MAPREDUCE-2858:
-----------------------------------------------
[Chiming in a bit late in the discussion]
Until now Hadoop webui was supporting authentication via servlet filters
initialized via the "hadoop.http.filter.initializers" config property. Alfredo
was integrated using such mechanism as well. In addition Alfredo support
pluggable authentication handlers.
This means there are 2 ways o handling security, one directly via
servlet-filters, the other via Alfredo authentication-handlers.
Wouldn't be enough to tell application managers to use the provided filters or
add their own?
And accessing NM HTTP resources could be done via a domain cookie given by the
RM to the AM at AM initialization time. This cookie could be verified by NMs
via a shared secret received at startup time from the RM (which could be a
random value generated at RM startup time).
Then we would not need whitelists or trusted proxies.
> 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
