[
https://issues.apache.org/jira/browse/YARN-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16310455#comment-16310455
]
Eric Yang commented on YARN-7516:
---------------------------------
[~ebadger] The same question has been ask by Vinod on Dec 11. It might be
technically correct to have
{{yarn.nodemanager.runtime.linux.docker.trusted-registry}}, but it is difficult
to find. My thinking was a bigger plan for {{yarn.docker.}} namespace for end
user friendly configuration. I am open to reuse
{{DOCKER_CONTAINER_RUNTIME_PREFIX}}, if majority of people prefer this.
I am not in favor of shifting all validation logic towards
container-executor.cfg. Java is still better than c in prevention of buffer
overflow. There is no guarantee that we don't introduce buffer overflow bugs
in root user validation. They can lead to new potential for spear phishing
attack. As the history has shown (YARN-7590), container-executor is not as
harden as we thought. If YARN user is compromised, then it can rewrite any
file as any other user on hdfs. We will have more coverage to setup defensive
mechanism in YARN code logic to extend our security perimeter rather than focus
solely on root user defensive mechanism only.
> 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]
