[
https://issues.apache.org/jira/browse/YARN-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446394#comment-16446394
]
Eric Badger commented on YARN-7654:
-----------------------------------
{quote}With docker, container-executor doesn't drop privileges to end user to
run docker cli. Instead, the end user uid:gid are passed to docker cli
utilities for docker to prepare the proper privileges to run the container. At
this time, docker run is running as root user, it will be possible for
--env-file to reference to a file in nmPrivate directory. If customer ask to
harden docker run to a specific user with docker group privileges only. We can
drop privileges in container-executor to a target user, i.e. end user himself
or the user configured via
yarn.nodemanager.linux-container-executor.nonsecure-mode.local-user. The
env-file in nmPrivate will not be readable by docker client. Hence, proposal 2
will create limitation for future hardening.
{quote}
Thanks for the explanation, [~eyang], that clears things up a ton. I can now
see what you're concerned about. That being said, this would be a pretty big
change to how we're doing things currently in the docker-hadoop space. Not that
we should go with the status quo just because, but it's harder to rationalize
making decisions based on things we're not even sure that we would do in the
future. For example, you say that a customer may want to have docker be run as
a user in the docker group instead of root. I'm wondering if there's really
much of a difference there. I can trivially root the box if I'm in the docker
group by using docker containers that would be started as root. I can overwrite
sudo, add myself to the sudo group, create setuid binaries, etc. So from that
angle, I'm not sure running as the docker group really buys us much other than
extra code bloat and I think that the act of giving users access to the docker
daemon actually decreases security by quite a bit because it's a large attack
surface that can be manipulated fairly easily.
{quote}
Docker can do this:
docker run -e KEY1=KEY2 --env-file=/path/to/password ...
The key value pair specified in yarnfile will be passed as command arguments.
Where the file path is supplied directly, they will be evaluated by docker and
not exposed as command arguments. YARN-8097 has example of how the file path is
specified.
{quote}
Yes, this is true, but this puts no restrictions on the potentially unknowing
user and what they can/cannot do. They might just pass all of their secrets on
the command line via the key-value pairs, since they don't know any better. If
it's unsafe, then why support it at all? When we're dealing with root, I think
it's best to move with caution and take out as many variables and moving parts
as possible.
> Support ENTRY_POINT for docker container
> ----------------------------------------
>
> Key: YARN-7654
> URL: https://issues.apache.org/jira/browse/YARN-7654
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: yarn
> Affects Versions: 3.1.0
> Reporter: Eric Yang
> Assignee: Eric Yang
> Priority: Blocker
> Attachments: YARN-7654.001.patch, YARN-7654.002.patch,
> YARN-7654.003.patch, YARN-7654.004.patch, YARN-7654.005.patch,
> YARN-7654.006.patch, YARN-7654.007.patch, YARN-7654.008.patch,
> YARN-7654.009.patch, YARN-7654.010.patch, YARN-7654.011.patch,
> YARN-7654.012.patch, YARN-7654.013.patch, YARN-7654.014.patch,
> YARN-7654.015.patch
>
>
> Docker image may have ENTRY_POINT predefined, but this is not supported in
> the current implementation. It would be nice if we can detect existence of
> {{launch_command}} and base on this variable launch docker container in
> different ways:
> h3. Launch command exists
> {code}
> docker run [image]:[version]
> docker exec [container_id] [launch_command]
> {code}
> h3. Use ENTRY_POINT
> {code}
> docker run [image]:[version]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
