[
https://issues.apache.org/jira/browse/YARN-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168584#comment-16168584
]
Eric Yang edited comment on YARN-5534 at 9/15/17 9:58 PM:
----------------------------------------------------------
Yarn-site.xml and core-site.xml are trusted configuration from Hdoop server
point of view. Hadoop Kerberos, and proxy users configuration are defined in
the *.xml files. WIthout trusting those configurations, Hadoop security fall
apart. There is keyword like final to lock configuration in place therefore an
overlay of Hadoop configuration can not alter the configuration values. Volume
white list in core-site.xml or yarn-site.xml are secured. There should be very
little configuration in container-executor.cfg file to govern uid and banned
user. The rest of the logic in core-site.xml is preferred to ensure the logic
is preprocessed in yarn user before handing off to root for execution. YARN
can act as a shielding user in pre-processing to make exploits more difficult.
was (Author: eyang):
Yarn-site.xml and core-site.xml are trusted configuration from Hdoop server
point of view. Hadoop Kerberos, and proxy users configuration are defined in
the *.xml files. WIthout trusting those configurations, Hadoop security fall
apart. There is keyword like final to lock configuration in place therefore an
overlay of Hadoop configuration can not alter the configuration values. Volume
white list in core-site.xml or yarn-site.xml are secured. There should be very
little configuration in container-executor.cfg file to govern uid and banned
user. The rest of the logic in core-site.xml is preferred to ensure the logic
is preprocessed in yarn user before handing off to root for execution.
> Allow whitelisted volume mounts
> --------------------------------
>
> Key: YARN-5534
> URL: https://issues.apache.org/jira/browse/YARN-5534
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: yarn
> Reporter: luhuichun
> Assignee: Shane Kumpf
> Attachments: YARN-5534.001.patch, YARN-5534.002.patch,
> YARN-5534.003.patch
>
>
> Introduction
> Mounting files or directories from the host is one way of passing
> configuration and other information into a docker container.
> We could allow the user to set a list of mounts in the environment of
> ContainerLaunchContext (e.g. /dir1:/targetdir1,/dir2:/targetdir2).
> These would be mounted read-only to the specified target locations. This has
> been resolved in YARN-4595
> 2.Problem Definition
> Bug mounting arbitrary volumes into a Docker container can be a security risk.
> 3.Possible solutions
> one approach to provide safe mounts is to allow the cluster administrator to
> configure a set of parent directories as white list mounting directories.
> Add a property named yarn.nodemanager.volume-mounts.white-list, when
> container executor do mount checking, only the allowed directories or
> sub-directories can be mounted.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
