[
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.
{quote}
To be consistent with the rest of the code, this should print a message that
privileged containers are disabled.
{quote}
This will be fixed.
{quote}
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.
{quote}
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.
{quote}
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 here.
{quote}
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 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: [email protected]
For additional commands, e-mail: [email protected]
