[
https://issues.apache.org/jira/browse/YARN-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391336#comment-15391336
]
Zhankun Tang edited comment on YARN-5360 at 7/25/16 4:39 AM:
-------------------------------------------------------------
[~sidharta-s], although running a container as root have security implications
by default, we can still use capabilities(already enabled in YARN-4258),
selinux and other linux kernel features to ensure the root user in container
has much less privileges than the real “root” in host. So for me, it is not
unsafe.
But as you mentioned, YARN's own complexity here prevents us from simply
removing "--user" option. Then let's focus on resolving these barriers which
enforces it and provide more flexible interface of what user to run the
container.
For discussion, I list them as below. We need more flexibility and we have
these barriers to cross:
* 1. Mounting /etc/passwd to container
** We should provide a way to toggle it since it override the original users
defined in Docker image. It shouldn't be mounted by default. ButI think this
already can be done by application thru YARN-4595. What we need to do is just
remove /etc/passwd bind-mount after this JIRA closed.
* 2. Exclusive permissions of local host files/directories mounted into Docker
container, especially "launch_container.sh"
** One simple way to solve this is just change the related permissions. For
instance, if unsecure mode, set 705 to launch_container.sh to allow other group
user run it and set 707 to log dirs to allow others to write log. If secure
mode, just set permissions as it is now.
* 3. Side effects that if we change the running user, things like log
aggregation would fail
** One simple way is that modify the YARN expects. For instance, don't expect
log permission same with submitting user if unsecure mode but check it when
secure mode.
And solving above items shouldn’t affect the secure mode requirement on user.
Behaviors in secure mode are just same as it is now. After solving these
barriers, we can provide application the interface in unsecure mode:
* an environment variable YARN_CONTAINER_RUNTIME_DOCKER_USER for application to
specify the running user in unsecure mode. If not provided, run as root or
defined user in Docker image
Thoughts?
was (Author: tangzhankun):
[~sidharta-s], although running a container as root have security implications
by default, we can still use capabilities(already enabled in YARN-4258),
selinux and other linux kernel features to ensure the root user in container
has much less privileges than the real “root” in host. So for me, it is not
unsafe.
But as you mentioned, YARN's own complexity here prevents us from simply
removing "--user" option. Then let's focus on resolving these barriers which
enforces it and provide more flexible interface of what user to run the
container.
For discussion, I list them as below. We need more flexibility and we have
these barriers to cross:
* 1. Mounting /etc/passwd to container
** We should provide a way to toggle it since it override the original users
defined in Docker image. It shouldn't be mounted by default. ButI think this
already can be done by application thru YARN-4595. What we need to do is just
remove /etc/passwd bind-mount after this JIRA closed.
* 2. Exclusive permissions of local host files/directories mounted into Docker
container, especially "launch_container.sh"
** One simple way to solve this is just change the related permissions. For
instance, if unsecure mode, set 705 to launch_container.sh to allow other group
user run it and set 707 to log dirs to allow others to write log. If secure
mode, just set permissions as it is now.
* 3. Side effects that if we change the running user, things like log
aggregation would fail
** One simple way is that modify the YARN expects. For instance, don't expect
log permission same with submitting user if unsecure mode but check it when
secure mode.
And solving above items shouldn’t affect the secure mode requirement on user.
Behaviors in secure mode are just same as it is now. After solving these
barriers, we can provide application the interface in unsecure mode:
* an environment variable YARN_CONTAINER_RUNTIME_DOCKER_USER for application to
specify the running user in unsecure mode
Thoughts?
> Decouple host user and Docker container user
> --------------------------------------------
>
> Key: YARN-5360
> URL: https://issues.apache.org/jira/browse/YARN-5360
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: yarn
> Reporter: Zhankun Tang
> Assignee: Zhankun Tang
>
> There is *a dependency between job submitting user and the user in the Docker
> image* in LCE currently. For instance, in order to run the Docker container
> as yarn user, we can choose set the
> "yarn.nodemanager.linux-container-executor.nonsecure-mode.local-user" to yarn
> and leave
> "yarn.nodemanager.linux-container-executor.nonsecure-mode.limit-users"
> default (true). Then LCE will choose yarn ( UID maybe 1001) as the user
> running jobs.
> LCE will mount the generated launch_container.sh (owned by the running job
> user) and /etc/passwd (*current the code is mounting to container's
> /etc/password, I think it's a mistake*) into the Docker container and
> utilizes "docker run --user=<run_as_user>" option to get it done internally.
> Mounting /etc/passwd to the container is a not good choice due to override
> original users defined in Docker image. As far as I know, since Docker v1.8
> (or maybe earlier), the Docker run command "--user=" option accepts UID and
> *when passing UID, the user does not have to exist in the container*. So we
> could use UID instead of user name to construct the Docker run command to
> eliminate the dependency that create the same user in the Docker image. This
> enables LCE the ability to launch any Docker container safely regardless what
> users in it.
> But this is not enough to decouple host user and Docker container user. The
> final solution we are searching for are focused on allowing users to run
> their Docker images flexibly without involving dependencies of YARN and make
> sure the container won't bring in security risk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
