[
https://issues.apache.org/jira/browse/YARN-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16322785#comment-16322785
]
Eric Badger commented on YARN-7516:
-----------------------------------
bq. The untrusted image will appear as privileged but all kernel privileges
dropped and disconnected all devices to outside world. Therefore, it isn't
really privileged, only appear as root in the docker container without real
root privileges to outside world.
I don't believe it disconnects all devices. According to the Docker
documentation, running as privileged automatically gives it access to *all*
devices. Removing --device in the case of a privileged container (as is done in
this patch) is moot, since the point of --device is to give containers access
to devices that they would normally only be able to access if they were
privileged.
https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
bq. If you are suggesting to disallow --privileged flag for untrusted image
completely, then it will limit our ability to try out new images before
verifying the untrusted image can be promoted to privileged registry. Does this
help to explain the reason that we don't check registry is privileged in
set_privileged flag?
I still don't quite understand why you require a container to be privileged to
try new images.
> 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]
