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-7516) Security check for trusted docker image
Date Wed, 31 Jan 2018 00:30:00 GMT

    [ https://issues.apache.org/jira/browse/YARN-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16346045#comment-16346045

Shane Kumpf commented on YARN-7516:

Hey Eric, thanks for the patches!

I'm sorry to jump in here late. I really like the premise, but I'll admit, I'm struggling
with the naming of this feature and have been thinking about alternatives. IMO, "docker.privileged-containers.registries"
implies containers requesting the --privileged flag, which isn't necessarily the case here.

To keep this short, I think we are looking at two ways that we launch containers, I'll refer
to them as "default-mode" and "yarn-mode".

In "default-mode", the following are removed:
 * Capabilities
 * Mounts
 * Privileged flag
 * Devices
 * User*
 * Launch command*

*Note that I think this patch needs to also remove overriding the user and launch command,
regardless of direction it is taken. With all the other features disabled, these don't make

In "default-mode", the container runs as defined by the image with no features. This has the
benefits of limiting any host access to improve security and making it easier to get started
with Docker on YARN. This is the direction the patch is already headed.

In "yarn-mode" some combination of those features would be enabled. Using these features requires
playing by the rules of being a "yarn-mode"  container. We already have controls around mounts,
devices, capabilities and privileged, but there are gaps, and the current defaults need review,
which we could tackle in another JIRA. This allows for some amount of "opt-in" or "opt-out"
of YARN or OS features for "yarn-mode" containers, which may be desirable.

With the modes defined, we could have a configuration similar to (example):
If the image begins with one of the prefix entries, run the container in that mode.

One benefit is that the settings don't have overlap with existing docker terms like privileged
and trusted and IMO, a registry is too large to use to determine which mode a container should
run in. Of course, the prefix can be used to specify an entire registry if desired. It would
also allow for getting as specific as needed.

A couple other thoughts
 * docker.default-mode.image.prefix should default to * for ease of use.
 * An image (or namespace or registry) would be promoted to yarn-mode once it has had the
proper vetting.
 * Any image not in either list would result in container failure. The image is not allowed.
 * yarn-mode list takes precedence, fall back to default-mode check.

Let me know what you think.

> Security check for trusted docker image
> ---------------------------------------
>                 Key: YARN-7516
>                 URL: https://issues.apache.org/jira/browse/YARN-7516
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Eric Yang
>            Assignee: Eric Yang
>            Priority: Major
>         Attachments: YARN-7516.001.patch, YARN-7516.002.patch, YARN-7516.003.patch, YARN-7516.004.patch,
YARN-7516.005.patch, YARN-7516.006.patch, YARN-7516.007.patch, YARN-7516.008.patch, YARN-7516.009.patch,
YARN-7516.010.patch, YARN-7516.011.patch, YARN-7516.012.patch, YARN-7516.013.patch, YARN-7516.014.patch,
> Hadoop YARN Services can support using private docker registry image or docker image
from docker hub.  In current implementation, Hadoop security is enforced through username
and group membership, and enforce uid:gid consistency in docker container and distributed
file system.  There is cloud use case for having ability to run untrusted docker image on
the same cluster for testing.  
> The basic requirement for untrusted container is to ensure all kernel and root privileges
are dropped, and there is no interaction with distributed file system to avoid contamination.
 We can probably enforce detection of untrusted docker image by checking the following:
> # If docker image is from public docker hub repository, the container is automatically
flagged as insecure, and disk volume mount are disabled automatically, and drop all kernel
> # If docker image is from private repository in docker hub, and there is a white list
to allow the private repository, disk volume mount is allowed, kernel capabilities follows
the allowed list.
> # If docker image is from private trusted registry with image name like "private.registry.local:5000/centos",
and white list allows this private trusted repository.  Disk volume mount is allowed, kernel
capabilities follows the allowed list.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message