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] [Commented] (YARN-7516) Security check for untrusted docker image
Date Fri, 12 Jan 2018 21:19:00 GMT

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

Eric Yang commented on YARN-7516:

[~ebadger] Thanks for the review.

To be consistent with the rest of the code, this should print a message that privileged containers
are disabled.

This will be fixed.

This test should fail, but doesn't. As I understand the patch, since the image is not from
a trusted registry, it should fail because of adding devices, capabilities, or mounts. However,
since it isn't asking for privilege it bypasses the trusted registry check.

Good catch here.  I was under the impression that if the image doesn't ask for a privileged
container, and running as specific user, we will let them interact with host device.  I see
the flawed in my logic, they could have sticky bit binary to gain root and make changes to
attached device.  Hence, we will denied them of cap-add/cap-drop and device attachment from
untrusted image even if they didn't ask for privileged container.

Also, going back to the registry parsing, what about the case where I build an image on the
node myself and then tag it with a name. Think about a single node cluster or similar or manually
pushing images to every node. If I do that, then docker.privileged-containers.registries would
prevent you from using the image as privileged since it didn't come from a registry. It would
just be local to the node. I'm not sure that parsing for a / delimiter is the best method

We can add docker.privileged-containers.registries=* as the default.  If wildcard is detected,
then check_trusted_image check is by passed completely and allow any image to run with privileged
mode.  Alternatively, user can tag the locally build image with trusted_registry/image name.
 This allows user to define docker.privileged-containers.registries=trusted_registry and use
the locally built image without push image to a trusted registry.  I am kind of in favor of
second solution to prevent accidental allowance of privileged containers.  What is your preference?

> 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, YARN-7516.008.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