[
https://issues.apache.org/jira/browse/YARN-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783236#comment-13783236
]
Todd Lipcon commented on YARN-1253:
-----------------------------------
On the security front, I see this as an improvement in compartmentalization.
Sometimes people have an HDFS cluster with lax security concerns for the data
within that cluster -- or already restrict access to submit jobs on the cluster
to folks who are considered trusted to access all of the data. Given that, the
concern of a malicious user masquerading as another on the cluster isn't a big
one -- or else they'd set up Kerberos security as you mentioned above.
That said, these clusters may still be configured with automatic NFS mounts,
and non-Kerberized NFS, in which case the ability to masquerade as another Unix
user is a big problem.
Let me give an example from my past -- a univerisity CS department where I
helped as a system administrator. In this environment, all users used
non-Kerberized nfs v3 to access a big filer with home directories. Users on the
sysadmin staff had a great deal of access on the filer, as well as general sudo
type access, sensitive SSH keys, etc stored within their home directories.
Obviously, students did not. In this same environment, we had shared compute
clusters (typically traditional HPCC, but some early experiments with Hadoop as
well back in ancient days). Different grad students shared these compute
clusters to perform their research jobs on, but security would not have been an
important consideration - within a trusted environment like a small university
research department, convenience outweighed security. That said, resource
allocation and isolation between users was important - I had many cases I had
to handle where students or professors up against a paper deadline got pretty
pissed off that some undergrad was monopolizing CPU cycles on shared machines.
In such an environment, the setup proposed by this JIRA would help. We could
not have simply used LCE, because that would have opened an attack vector: any
student could submit a job as "toddlipcon" and then use my NFS access to
essentially gain department-wide root. Without using LCE, there would be poor
resource isolation (lacking cgroups).
I'm certain that there are other environments as well where Unix user
masquerading opens a lot of attack vectors, but where within-Hadoop strong auth
is not a requirement.
> Changes to LinuxContainerExecutor to use cgroups in unsecure mode
> -----------------------------------------------------------------
>
> Key: YARN-1253
> URL: https://issues.apache.org/jira/browse/YARN-1253
> Project: Hadoop YARN
> Issue Type: New Feature
> Components: nodemanager
> Affects Versions: 2.1.0-beta
> Reporter: Alejandro Abdelnur
> Assignee: Roman Shaposhnik
> Priority: Blocker
>
> When using cgroups we require LCE to be configured in the cluster to start
> containers.
> When LCE starts containers as the user that submitted the job. While this
> works correctly in a secure setup, in an un-secure setup this presents a
> couple issues:
> * LCE requires all Hadoop users submitting jobs to be Unix users in all nodes
> * Because users can impersonate other users, any user would have access to
> any local file of other users
> Particularly, the second issue is not desirable as a user could get access to
> ssh keys of other users in the nodes or if there are NFS mounts, get to other
> users data outside of the cluster.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
