[
https://issues.apache.org/jira/browse/YARN-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446205#comment-16446205
]
Eric Yang edited comment on YARN-7654 at 4/20/18 8:14 PM:
----------------------------------------------------------
[~ebadger]
{quote}
I'm confused by this point. Can you explain further? In what circumstance would
the user need to look in the nmPrivate directory? AFAIK the NM will always
invoke the container-executor (a root setuid binary) to start the docker
container. After that, I don't see why the user would need access to the
nmPrivate directory outside of debugging (where there have been other ways
discussed on how to deal with this).
{quote}
Without docker in the picture for a moment, Container-executor runs as root
privilege then drop privileges to end user privilege to run java vm. Therefore
all files are prepared and initialized by container-executor to end user
privileges in localizer directory for launch. NmPrivate directory is a
contract between node manager and container-executor to exchange private
information.
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}
How so? The question here is whether the environment variables will be passed
on the command line or via an env file whose path is passed via the command
line. I don't see how the docker run command can pass the environment variables
on the command line while also masking them to the rest of the world. If you
are localizing an env file inside of the docker container after the docker run
is invoked, then that is outside of the scope of this specific discussion.
{quote}
Docker can do this:
{code}
docker run -e KEY1=KEY2 --env-file=/path/to/password ...
{code}
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}
I think this is the most important piece here. If we (rightfully) aren't
willing to put secrets or other untrusted code on the command line, then we by
definition cannot go with proposal 1. Regardless of YARN-8079, I do not see a
path forward with proposal 1 that will prevent a user from unknowingly passing
secrets on the command line
{quote}
My side of the arguement is to use YARN-8097. Sorry the JIRA numbers are very
similar, please make sure that you evaluated the correct number. Thanks. I
agree with the potential of unknowing passing secrets on the command line for
first time user, but YARN-8097 offers solution to resolve that concern.
was (Author: eyang):
[~ebadger]
{quote}
I'm confused by this point. Can you explain further? In what circumstance would
the user need to look in the nmPrivate directory? AFAIK the NM will always
invoke the container-executor (a root setuid binary) to start the docker
container. After that, I don't see why the user would need access to the
nmPrivate directory outside of debugging (where there have been other ways
discussed on how to deal with this).
{quote}
Without docker in the picture for a moment, Container-executor runs as root
privilege then drop privileges to end user privilege to run java vm. Therefore
all files are prepared and initialized by container-executor to end user
privileges in localizer directory for launch. NmPrivate directory is a
contract between node manager and container-executor to exchange private
information.
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}
How so? The question here is whether the environment variables will be passed
on the command line or via an env file whose path is passed via the command
line. I don't see how the docker run command can pass the environment variables
on the command line while also masking them to the rest of the world. If you
are localizing an env file inside of the docker container after the docker run
is invoked, then that is outside of the scope of this specific discussion.
{quote}
Docker can do this:
{code}
docker run -e KEY1=KEY2 --env-file=/path/to/password ...
{code}
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-8079 has example of how the file path
is specified.
{quote}
I think this is the most important piece here. If we (rightfully) aren't
willing to put secrets or other untrusted code on the command line, then we by
definition cannot go with proposal 1. Regardless of YARN-8079, I do not see a
path forward with proposal 1 that will prevent a user from unknowingly passing
secrets on the command line
{quote}
My side of the arguement is to use YARN-8097. Sorry the JIRA numbers are very
similar, please make sure that you evaluated the correct number. Thanks. I
agree with the potential of unknowing passing secrets on the command line for
first time user, but YARN-8097 offers solution to resolve that concern.
> 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: [email protected]
For additional commands, e-mail: [email protected]
