[
https://issues.apache.org/jira/browse/YARN-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16324484#comment-16324484
]
Eric Badger commented on YARN-7516:
-----------------------------------
[~eyang], thanks for the patch.
{noformat}
+ // Disable set privileged if image is not trusted.
+ if (check_trusted_image(command_config, conf) != 0) {
+ ret = PRIVILEGED_CONTAINERS_DISABLED;
+ goto free_and_exit;
{noformat}
To be consistent with the rest of the code, this should print a message that
privileged containers are disabled.
{noformat}
+ file_cmd_vec.push_back(std::make_pair<std::string, std::string>(
+ "[docker-command-execution]\n"
+ " docker-command=run\n name=container_e1_12312_11111_02_000001\n
image=docker-image\n user=test\n hostname=host-id\n"
+ "
ro-mounts=/var/log:/var/log,/var/lib:/lib,/usr/bin/cut:/usr/bin/cut\n
rw-mounts=/tmp:/tmp\n"
+ " network=bridge\n devices=/dev/test:/dev/test\n net=bridge\n"
+ " cap-add=CHOWN,SETUID\n cgroup-parent=ctr-cgroup\n
detach=true\n rm=true\n group-add=1000,1001\n"
+ " launch-command=bash,test_script.sh,arg1,arg2",
+ "run --name='container_e1_12312_11111_02_000001' --user='test' -d --rm
--net='bridge' -v '/var/log:/var/log:ro' -v '/var/lib:/lib:ro'"
+ " -v '/usr/bin/cut:/usr/bin/cut:ro' -v '/tmp:/tmp'
--cgroup-parent='ctr-cgroup' --cap-drop='ALL' "
+ "--cap-add='CHOWN' --cap-add='SETUID' --hostname='host-id'
--group-add '1000' --group-add '1001' "
+ "--device='/dev/test:/dev/test' 'docker-image' 'bash'
'test_script.sh' 'arg1' 'arg2' "));
{noformat}
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.
{noformat:title=check_trusted_image()}
if (value != NULL && strcmp(value, "true") == 0) {
{noformat}
I think this is the line that is causing the error. We are only actually doing
the trusted image check if we're asking for privilege.
> 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: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
