[
https://issues.apache.org/jira/browse/YARN-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16091824#comment-16091824
]
Shane Kumpf commented on YARN-5534:
-----------------------------------
{quote}
So you're proposing having a whitelist of volumes that can be bind-mounted that
is defined by the NM and then have the user supply a list of volumes that need
to be a subset of that whitelist?
{quote}
That is correct. The user will opt-in to bind mounts they require, and those
bind mount must be in the whitelist (or must be localized resources) for the
operation to succeed.
{quote}
What about volumes that the NM always wants to mount regardless of the user?
{quote}
Can you help me understand the use case here? While there are mounts that will
be commonly needed by containers, I'm not sure of any bind mounts that every
container will require. I'd prefer an opt-in model so we don't needless expose
host artifacts when they aren't required. However, it wouldn't be very
difficult to add this feature, so let me know and I can work to add it.
{quote}
My question is whether they can leverage these mount points to gain root in the
container if minimal capabilities (aka not SETUID/SETGID/etc.) are given.
{quote}
Great questions. I agree it is possible for them to shoot themselves in the
foot, but I don't believe that adding support for bind mounts opens up
additional risk with regard to overriding libraries and binaries. Avoiding
privileged containers and limiting capabilities is use case dependent, but best
practices should be followed to limit the attack surface.
Having said that, it seems there could be a need for admins to be able to
control the destination mount path within the container. However, the
implementation becomes less straight forward for localized
resources/distributed cache. Currently we support arbitrary destination paths
within the container for localized resources. Consider the hbase container use
case, where hbase-site.xml is localized and the hbase processes in the
container expect hbase-site.xml to be in /etc/hbase/conf. The admin doesn't
know the full path to the localized resources up front, so it wouldn't be
possible for the admin to define these localized resources in the whitelist. We
could possibly address this through special syntax (i.e.
$$LOCALIZED_PATH$$/hbase-site.xml:/etc/hbase/conf/hbase-site.xml:ro") if this
is a concern. Thoughts?
> 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
>
>
> 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
