[
https://issues.apache.org/jira/browse/YARN-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445904#comment-16445904
]
Jason Lowe commented on YARN-7654:
----------------------------------
{quote}No additional file to clean up, environment variables can be seen from
docker run command line
{quote}
This is not a pro, it's a con. Users will pass secrets to the container via
environment variables, and anyone on the system could casually observe them via
the {{ps}} command.
{quote}Separation of duty, allow system administrator to run services and
override developer supplied environment variables
{quote}
This is not specific to proposal 1. System administrator variables can be (and
already are) overridden by the nodemanager before the environment variables are
passed down to the container executor.
{quote}Can hide environment secrets from stdout.txt log file
{quote}
Again I don't see how this is specific to proposal 1. IIUC proposal 1 is going
to expose all the enviroment variables in the docker command file that is
copied to the log directory. This could be avoided for security reasons, but it
could also be avoided for proposal 2 as well. Proposal 2 does not require the
environment file for the docker run command to be in the container working
directory.
{quote}No filename clashes in localizer directory because user define the
env-file filename
{quote}
There are no filename clashes. The env file is being written to the container
private directory, the same place tokens are written by the nodemanager today.
This is not the container working directory where user files are located, so
there's no possibility of a collision.
{quote}Save 1 inode for not duplicating env-file in log directory, if log
aggregation is not enabled
{quote}
The env file can be copied into the existing docker.cmd file or other
debugging-file-for-launch that already exists which eliminates the extra inode
concern along with any file collision potential in the log directory.
{quote}No separation of duty, only one way to define environment variables.
{quote}
This is not a con, it's a pro. Otherwise it's a maintenance burden to support
two independent code paths that essentially are doing the same thing.
{quote}Environment file is copied to log directory, therefore environment
secrets is still visible to yarn logs cli command
{quote}
This is the same issue as proposal 1, and as I mentioned above, we don't have
to copy the environment file to the log directory. It's only for debugging
purposes for the user. Either we're going to copy environment variable settings
to the log directory for debugging in both proposals, or we're not going to do
this for both proposals.
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.
That means we need to go the env-file route. If we have to go the env-file
route for security reasons then I don't understand why we would need yet
another way to set environment variables.
> 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
