[
https://issues.apache.org/jira/browse/YARN-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119965#comment-16119965
]
Eric Badger commented on YARN-5534:
-----------------------------------
bq. For example(just made up), an admin may want to mount /data-volume into
every container by some subset of users. container-executor.cfg should have a
setting permitting the mounting of /data-volume but yarn-site.xml should have
feature to mount it into every container for those users. Does that make sense?
I still don't see why the overall mounting setting would be in
container-executor.cfg while the user-specific setting would be in
yarn-site.xml. If we're looking at this from a security perspective, the volume
mount is either a potential attack vector or not. If it's not, then we don't
really care whether anyone can mount it and then I would say we should just put
everything in yarn-site.xml. If we assume that it is a potential attack vector,
then we very much care that only certain users can mount that volume. In that
case, I don't see why we would put that whitelist of users in yarn-site.xml, if
we're also assuming that yarn-site.xml is potentially untrusted (I assume the
reason we're putting things into container-executor.cfg is because it is only
root read/writable).
So basically my main points are:
1. If yarn-site.xml is untrusted, then we can't put any configs with potential
security-related consequences in there (e.g. which volumes are whitelisted)
2. If yarn-site.xml is trusted, then I don't know why we need to move any of
the configs into container-executor.cfg
> 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: [email protected]
For additional commands, e-mail: [email protected]
