hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Yang (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (YARN-7516) Security check for untrusted docker image
Date Thu, 11 Jan 2018 18:23:01 GMT

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

Eric Yang edited comment on YARN-7516 at 1/11/18 6:22 PM:
----------------------------------------------------------

[~ebadger] Thanks for the review.  The untrusted image will appear as privileged but all kernel
privileges dropped and disconnected all devices to outside world.  Therefore, it isn't really
privileged, only appear as root in the docker container without real root privileges to outside
world.  This helps to run as a sandbox for simulation test.  The generated docker command
looks like:

{code}
docker run --privileged --cap-drop='ALL' ... centos:latest bash
{code}

If you are suggesting to disallow --privileged flag for untrusted image completely, then it
will limit our ability to try out new images before verifying the untrusted image can be promoted
to privileged registry.  Does this help to explain the reason that we don't check registry
is privileged in set_privileged flag?


was (Author: eyang):
[~ebadger] Thanks for the review.  The untrusted image will appear as privileged but all kernel
privileges dropped.  Therefore, it isn't really privileged, only appear as root in the docker
container without real root privileges to outside world.  This helps to run as a sandbox for
simulation test.  The generated docker command looks like:

{code}
docker run --privileged --cap-drop='ALL' ... centos:latest bash
{code}

If you are suggesting to disallow --privileged flag for untrusted image completely, then it
will limit our ability to try out new images before verifying the untrusted image can be promoted
to privileged registry.  Does this help to explain the reason that we don't check registry
is privileged in set_privileged flag?

> Security check for untrusted 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
>         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
>
>
> 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
capabilities.
> # 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
(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