[
https://issues.apache.org/jira/browse/YARN-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16311772#comment-16311772
]
Eric Yang commented on YARN-7516:
---------------------------------
[[email protected]] . The privileged container is often used by QA
to test systemd image that spawn a virtual hadoop cluster inside of containers.
This is one of our primary use cases, hence, we are adding security feature to
prevent QA from creating havoc on the cluster. I think suggestion of using
trusted key is a good one, but I did not find information about trusting image
using our key only. The {{--disable-trust-content}} flag will download signed
content from anyone who generated content-trust. It seems like trusting
repository and individual image can go hand in hand to increase the strength of
the security check. However, I am inclined to move trusting individual image
logic to a new JIRA as further enhancement when the detail steps have been
figured out.
I think it is reasonable to have local validation done in root, where network
validation should be done prior to becoming root, or after dropping privileges.
This will reduce possible spear phishing holes using root privileges. I will
change the logic to move repository prefix validation to container-executor,
and move the configuration key to container-executor.cfg, given that everyone
have voiced the same concern in keeping effort that was started in YARN-6623.
Thank you all for the feedback.
> 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
>
>
> 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]
