[
https://issues.apache.org/jira/browse/MAPREDUCE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126222#comment-13126222
]
Luke Lu commented on MAPREDUCE-2858:
------------------------------------
bq. If I've understood the proposal (cough design doc ), ultimately one could
allow operators to configure access into a cluster (e.g. disallow, rather than
warn for "untrusted" responses in a production cluster)? That's a cool
property, but an esoteric requirement.
The ultimate goal of the proxy is *not* providing webapp access control for the
cluster, which happens to be a useful side-effect. The proxy is a counter
measure for potentially unsafe webapps *inside* the cluster, which also
provides useful tracking info for logging, in case bad things happen. It also
serves as user authentication delegate for webapps inside the cluster.
bq. A proxy to warn operators/strip potentially dangerous scripts is an
awfully specialized widget.
What's are some non-specialized alternatives?
bq. If one wants to proxy/scrape all requests, wouldn't a standard,
deployment-specific set of rules work as well? I'm sorry if I've also
misapprehended the threat or overestimated the capabilities of generic HTTP
proxies.
As far as I know, there are no generic HTTP proxies that does js
filtering/whitelisting. I'd be happy to use a standard proxy that can do this.
bq. It assumes a lot about the deployment, too.
It *only* assumes that the proxies are running on trusted IP addresses, which
is quite reasonable for typical deployment, where you have dedicated servers
for "master" (RM, NN, ZK). The proxies use little resource and can run on these
nodes.
bq. How is security harmed if we authenticate using [something derived from]
the app token?
It's not harmed, just overkill and unnecessary, which also assumes a shared
secret between the authenticator and the service provider. ip whitelisting is
much easier in this case and more generally applicable.
bq. but this feature will require tooling or documentation to maintain that
mapping, right?
The whitelist is generated at build time and put into conf/proxy/whitelist
directory at assembly time. So I'd say for standard M/R apps, it happens
automatically. Future improvement can include a centralized whitelist db and
associated webapp to review/approve/manage the whitelists.
bq. but this hurdle to integration all-but-guarantees that most... won't.
First the standard MR apps will be integrated automatically. Second, even if
some random apps is not providing whitelist, it's OK, as the end user
experience is not affected. It's just that when admin/other users happen to
look at these webapps, you'll see the obligatory warning, which they can ignore
(which along with all proxy actions will be logged) if they choose to. The
proxy can make these choices persistent with cookies as well.
> 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
