[ 
https://issues.apache.org/jira/browse/YARN-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446205#comment-16446205
 ] 

Eric Yang commented on YARN-7654:
---------------------------------

[~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 number very 
similar, please make sure that you evaluated the correct number.  Thanks.

> 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

Reply via email to