[
https://issues.apache.org/jira/browse/YARN-9834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942396#comment-16942396
]
Eric Yang edited comment on YARN-9834 at 10/2/19 12:17 AM:
-----------------------------------------------------------
{quote}Like I already explained in our meeting. There is no concrete example of
the "conflict". The design will restrict pool users from creating folders
outside of Yarn node manager usercache folder. The design guarantees the local
files are all deleted before the local pool user can be reused.
As I explained above. There will be no user directory (/home/<user>), and one
local pool user cannot access other local pool user's usercache folder. We have
e2e test cases to cover all kinds of scenarios like this.
{quote}
The above statement is false. There is no code in this patch to help working
directory isolation. YARN container is just a directory. The user process is
not jailed into the working directory by any stretch of imagination. Hence you
are making a design decision based on false assumption that user program would
not access outside of working directory. This is a big mistake. You should not
insist on something that is not true in reality.
{quote}We cannot run Docker container inside Docker container. We are relying
on running Yarn container process as different local user for the isolation,
which is based on the existing Yarn Secure Container implementation in
LinuxContainerExecutor.
{quote}
LinuxContainerExecutor is not designed for your use case. Your modification is
only going to jeopardize others who already have heavily reliance for the
existing Unix security model for LinuxContainerExecutor. Docker in Docker on
YARN is possible, we have in house cloud implementation based on this. Hadoop
trunk code base already have all the necessary knobs to improve isolation. I
will ask you nicely one last time to implement Pool user container executor
with proper path isolation and process isolation.
{quote}How could user job play tricks to modify Yarn node manager's
configuration? If they could, they could just steal node manager's keytab file
and talk to Yarn resource manager directly.
{quote}
Please look at your own patch carefully, line 695 of
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager/src/main/java/org/apache/hadoop/yarn/server/nodemanager/containermanager/localizer/ResourceLocalizationService.java
is not returning any thing nor breaking. It smash into case APPLICATION:. This
is wrong, and there are several ways to exploit it.
was (Author: eyang):
{quote}Like I already explained in our meeting. There is no concrete example of
the "conflict". The design will restrict pool users from creating folders
outside of Yarn node manager usercache folder. The design guarantees the local
files are all deleted before the local pool user can be reused.
As I explained above. There will be no user directory (/home/<user>), and one
local pool user cannot access other local pool user's usercache folder. We have
e2e test cases to cover all kinds of scenarios like this.{quote}
The above statement is false. There is no code in this patch to help working
directory isolation. YARN container is just a directory. The user process is
not jailed into the working directory by any stretch of imagination. Hence you
are making a design decision based on false assumption that user program would
not access outside of working directory. This is a big mistake. You should
not insist on something that is not true in reality.
{quote}We cannot run Docker container inside Docker container. We are relying
on running Yarn container process as different local user for the isolation,
which is based on the existing Yarn Secure Container implementation in
LinuxContainerExecutor.{quote}
LinuxContainerExecutor is not designed for your use case. Your modification is
only going to jeopardize others who already have heavily reliance for the
existing Unix security model for LinuxContainerExecutor. Docker in Docker on
YARN is possible, we have in house cloud implementation based on this. Hadoop
trunk code base already have all the necessary knobs to improve isolation. I
will ask you nicely one last time to implement Pool user container executor
with proper path isolation and process isolation.
{quote}How could user job play tricks to modify Yarn node manager's
configuration? If they could, they could just steal node manager's keytab file
and talk to Yarn resource manager directly.{quote}
Please look at your own patch carefully, [line
695|hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager/src/main/java/org/apache/hadoop/yarn/server/nodemanager/containermanager/localizer/ResourceLocalizationService.java]
is not returning any thing nor breaking. It smash into case APPLICATION:.
This is wrong, and there are several ways to exploit it.
> Allow using a pool of local users to run Yarn Secure Container in secure mode
> -----------------------------------------------------------------------------
>
> Key: YARN-9834
> URL: https://issues.apache.org/jira/browse/YARN-9834
> Project: Hadoop YARN
> Issue Type: Bug
> Components: nodemanager
> Affects Versions: 3.1.2
> Reporter: shanyu zhao
> Assignee: shanyu zhao
> Priority: Major
> Attachments: YarnSecureContainerWithPoolOfLocalUsers.pdf
>
>
> Yarn Secure Container allows separation of different user's local files and
> container processes running on the same node manager. This depends on an out
> of band service such as SSSD/Winbind to sync all domain users to local
> machine that runs Yarn node manager. *Hadoop code only works with local
> users*.
> Winbind/SSSD user sync has lots of overhead, especially for large
> corporations. Also if running Yarn node manager inside Kubernetes cluster
> (meaning node managers running inside Docker container), it doesn't make
> sense for each Docker container to domain join with Active Directory and sync
> a whole copy of domain users to the Docker container.
> We need an optional light-weighted approach to enable Yarn Secure Container
> in secure mode, as an alternative to AD domain join and SSSD/Winbind based
> user-sync service.
> Today, class LinuxContainerExecutor already supports running Yarn container
> process as one designated local user in non-secure mode.
> *We can add new configurations to Yarn, such that with LinuxContainerExecutor
> we can pre-create a pool of local users on each Yarn node manager. At
> runtime, Yarn node manager allocates a local user to run the container
> process, for the domain user that submits the application*. When all
> containers of that user are finished and all files belonging to that user are
> deleted, we can release the allocation and allow other users to use the same
> local user to run their Yarn containers.
> Please look at attached design doc for more details.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
