[
https://issues.apache.org/jira/browse/YARN-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446109#comment-16446109
]
Eric Badger commented on YARN-7654:
-----------------------------------
bq. Possible limitation when docker run user != YARN user, nmPrivate directory
is limited to yarn user.
[~eyang], 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).
bq. The problem associated with having the environment variable file in node
manager private directory, will require docker to run as root
Again, I don't see how the NM would start a docker container that wasn't
invoked via the root setuid binary container-executor. Is there some way that I
have missed?
bq. This is not true, you can combine YARN-8079 to hide secrets, and they will
not be revealed via ps command.
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}
To me this all boils down to the fact that we need to keep the environment
variables off the command-line because:
1) They contain unfiltered data from an untrusted source being passed on the
command-line to a root program.
2) They are likely to contain sensitive information.
{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
> 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
