hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinod Kumar Vavilapalli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-7506) Overhaul the design of the Linux container-executor regarding Docker and future runtimes
Date Thu, 16 Nov 2017 22:17:00 GMT

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

Vinod Kumar Vavilapalli commented on YARN-7506:
-----------------------------------------------

This is either a dup or sub-task of YARN-5673 I think.

Originally, moving some / most of the container-executor code into dynamic modules and let
developers code these modules potentially in different languages was a concrete goal of YARN-5673.
We have realized a bulk of our goals of cleaning executor up via YARN-6623 (though the title
there is non-descriptive).

I think it is still a goal. But for that, we need to modularize container-executor and let
it load modules dynamically.

Side note: One more important consideration in the container-executor design was to not have
long running root processes as it may increase the attack scope. Assuming that is still intact.

> Overhaul the design of the Linux container-executor regarding Docker and future runtimes
> ----------------------------------------------------------------------------------------
>
>                 Key: YARN-7506
>                 URL: https://issues.apache.org/jira/browse/YARN-7506
>             Project: Hadoop YARN
>          Issue Type: Wish
>          Components: nodemanager
>            Reporter: Miklos Szegedi
>              Labels: Docker, container-executor
>
> I raise this topic to discuss a potential improvement of the container executor tool
in node manager.
> container-executor has two main purposes. It executes Linux *system calls not available
from Java*, and it executes tasks *available to root that are not available to the yarn user*.
Historically container-executor did both by doing impersonation. The yarn user is separated
from root because it runs network services, so *the yarn user should be restricted* by design.
Because of this it has it's own config file container-executor.cfg writable by root only that
specifies what actions are allowed for the yarn user. However, the requirements have changed
with Docker and that raises the following questions:
> 1. The Docker feature of YARN requires root permissions to *access the Docker socket*
but it does not run any system calls, so could the Docker related code in container-executor
be *refactored into a separate Java process ran as root*? Java would make the development
much faster and more secure. 
> 2. The Docker feature only needs the Docker unix socket. It is not a good idea to let
the yarn user directly access the socket, since that would elevate its privileges to root.
However, the Java tool running as root mentioned in the previous question could act as a *proxy
on the Docker socket* operating directly on the Docker REST API *eliminating the need to use
the Docker CLI*. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org


Mime
View raw message