hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shane Kumpf (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-5534) Allow whitelisted volume mounts
Date Tue, 18 Jul 2017 17:12:00 GMT

    [ 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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org


Mime
View raw message