[
https://issues.apache.org/jira/browse/YARN-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322627#comment-16322627
]
Eric Badger commented on YARN-7516:
-----------------------------------
{noformat}
+The default behavior is disallow any privileged docker containers. When
`docker.privileged-containers.enabled` is set to enabled, docker image can run
with root privileges in the docker container, but access to host level devices
are disabled. This allows developer and tester to run docker images from
internet without causing harm to host operating system.
+
+When docker images have been certified by developers and testers to be
trustworthy. The trusted image can be promoted to trusted docker registry.
System administrator can define `docker.privileged-containers.registries`, and
setup private docker registry server to promote trusted images.
{noformat}
So after this patch, if docker.privileged-containers.enabled is set to true, an
image downloaded from a registry that isn't in
docker.privileged-containers.registries could still run as privileged? This
doesn't seem correct to me, if I'm reading this right. I think we should add a
check to {{set_privileged}} to make sure that the registry is privileged.
> 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: [email protected]
For additional commands, e-mail: [email protected]
