hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-7430) User and Group mapping are incorrect in docker container
Date Tue, 14 Nov 2017 19:33:00 GMT

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

Eric Yang commented on YARN-7430:

I agree, but I was under the assumption that this was acceptable behavior for hadoop. I would
also like to get rid of this so that we can ensure that hadoop is secured, but this removes
the ability to run containers based on arbitrary docker images. Basically, this would modify
the longterm plan for docker in hadoop so we need to make sure that we understand what the
longterm plan is.

Hadoop provide flexibility to run in both secure and insecure environments.  HDFS is not governed
by uid:gid because the security design is to secure the perimeter of cluster nodes to guarantee
consistency in ACL.  Username and group name are unique identifier without the need of uid:gid.
 For YARN, Linux container-executor is already enforcing uid:gid to ensure data written locally
can be read back by ACL enforced by Linux.  Hadoop implicitly followed Linux model security
without been full compliance.  There are pro and cons in the extra flexibility.  This enable
the system to run in secure model (Kerberos enabled) to behave like Linux.  This also enables
cloud system to simulate simple security where the container, can run with default container
executor or other implementation of container executor to keep system secure.  

This JIRA is focusing on a default setting that prevents unintended user to gain extra root
privileges even in a system that is configured for "simple" or "Kerberos" security mode with
Linux container executor.  Linux container executor by it's own name representing the security
model is honoring what Linux system expects.  It would be good for Docker container to play
by the same rule.

It is entirely possible to implement other security mechanism to validate processes rights
vs file system rights with Docker for some cloud use case where not all users are translated
to a unix user.  However, the new branch of code would not reside in Linux container executor.
 Does this address the concern of long term plan?

> User and Group mapping are incorrect in docker container
> --------------------------------------------------------
>                 Key: YARN-7430
>                 URL: https://issues.apache.org/jira/browse/YARN-7430
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: security, yarn
>    Affects Versions: 2.9.0, 3.0.0
>            Reporter: Eric Yang
>            Assignee: Eric Yang
>            Priority: Blocker
>         Attachments: YARN-7430.001.patch, YARN-7430.png
> In YARN-4266, the recommendation was to use -u [uid]:[gid] numeric values to enforce
user and group for the running user.  In YARN-6623, this translated to --user=test --group-add=group1.
 The code no longer enforce group correctly for launched process.  
> In addition, the implementation in YARN-6623 requires the user and group information
to exist in container to translate username and group to uid/gid.  For users on LDAP, there
is no good way to populate container with user and group information. 

This message was sent by Atlassian JIRA

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

View raw message