[
https://issues.apache.org/jira/browse/MAPREDUCE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125571#comment-13125571
]
Chris Douglas commented on MAPREDUCE-2858:
------------------------------------------
bq. The proxy is general enough to filter any webapp (including NM, so we can
allow NM webapps on ephemeral ports, which is nice for testing etc.) in the
cluster
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. A proxy to warn operators/strip
potentially dangerous scripts is an awfully specialized widget. It assumes a
lot about the deployment, too. 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.
How is security harmed if we authenticate using [something derived from] the
app token?
Bobby's points, particularly on operability, haven't really been addressed. I
grasp what a whitelist of SHA-1 hashes effects, but keeping that synchronized
with cluster software, handling rolling upgrades, etc. are solvable, but
avoidable irritations. I assume your design doc will go into detail, but this
feature will require tooling or documentation to maintain that mapping, right?
bq. If people don't want to use Hamlet, they have to find a comparable solution
(lack of a comparable solution indicates an incentive to switch to a better
framework
:) The author's willingness to adopt Hamlet should not be strong/dominant
factor in her integration with Hadoop's security layer. That's different than
saying a factor in creating secure webapps- and I'll trust that Hamlet does
that well- but this hurdle to integration all-but-guarantees that most... won't.
> 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
