[
https://issues.apache.org/jira/browse/MAPREDUCE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134098#comment-13134098
]
Robert Joseph Evans commented on MAPREDUCE-2858:
------------------------------------------------
@Alejandro,
Perhaps I should explain a little bit better how the code currently works.
When a user wants to go to the UI for a running application they will either
click on the link in the RM UI, or they will copy and paste in the URI that is
returned by the RM. Instead of returning the link exactly as was given to the
RM by the AM, the RM will rewrite the URI to go through the proxy. It will
rewrite the link to look like
http://<PROXY_HOST>:<PROXY_PORT>/proxy/NEEDSCHECK/<APP_ID>
When the user goes to the proxy server, which by default runs on the RM, but
does not have to, it will parse out the data from the URI. It will find the
<APP_ID> and look up the state of the application, the user that owns that
application, and the original not proxied URI of the application's interface.
If the URI indicates that the user needs to be checked, by the NEEDSCHECK path,
then it will compare the current user against the owner of the application. If
the user is not the same then a warning page is displayed with a link to a
version of the URI with CHECKED instead of NEEDSCHECK. If the URI is not
marked as NEEDSCHECK, or the user is the same as the owner then the proxy will
take the path after the <APP_ID> append it to the end of the path after the
original URI and have the URI to send through the proxy.
If the app is in a completed state, then the proxy assumes the URI must be OK,
because the app should have no servers running any longer, so instead of doing
a proxy it will redirect the user to the new URI. If the app is still running
then the proxy will create a connection to the URI, replacing the cookies with
a single cookie indicating the user that was logged in. It then passes the
response through unchanged.
When launching an Application Master an environment variable is set that
indicates to the Application Master where in the proxy it is based. Currently
that would be something like /proxy/CHECKED/application_12345_00001/ This is
then pre-pended, by the Application Master to all of the URIs that it produces
that would are not relative or fully qualified. For example /static/hadoop.png
would then become /proxy/CHECKED/application_12345_00001/static/hadoop.png.
Similarly a new Filter is added that is intended to run on the AM. IT will
verify that a request is coming from the IP address of the proxy. If it is not
it will redirect the user to go through the proxy. If the request is coming
from the proxy then the filter will read in the cookie indicating the user set
by the proxy, and set the user in the HttpServletRequest accordingly.
What I am suggesting is that if you want to have a config to completely disable
the proxy it would just require the patch to be changed so that the following
does not happen if the proxy is disabled.
# The new Filter will not replace the other filters when setting up a MR Job
to run.
# The URI returned by the ApplicationAttemptImpl will not be modified at all,
so the proxied URI is identical to the original URI.
# The environment variable indicating to the AM the ROOT of the proxy is not
set.
After thinking about it now too, I think we need a way to disable the user
checking altogether, because currently if security is disabled, then Dr Who.,
or webuser will always have to click through to get to their UI, which is bad.
I will add in the change to disable the user check if security is disabled.
If you want me to disable the proxy all together when security is disabled I
can too, but that would also disable the proxy forwarding from AM to History
Server.
> 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, 0.24.0
> Reporter: Luke Lu
> Assignee: Robert Joseph Evans
> Priority: Blocker
> Fix For: 0.23.0
>
> Attachments: MR-2858-branch-0.23.txt, MR-2858-branch-0.23.txt,
> MR-2858.txt, MR-2858.txt
>
>
> 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
