[jira] [Comment Edited] (MESOS-2333) Securing Sandboxes via Filebrowser Access Control

["Alexander Rojas (JIRA)" <ji...@apache.org>]

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

Alexander Rojas edited comment on MESOS-2333 at 6/2/15 12:52 PM:
-----------------------------------------------------------------

Discarded: -https://reviews.apache.org/r/31228/ m-
Discarded: -https://reviews.apache.org/r/31676/ m-


was (Author: arojas):
https://reviews.apache.org/r/31228/
https://reviews.apache.org/r/31676/

> Securing Sandboxes via Filebrowser Access Control
> -------------------------------------------------
>
>                 Key: MESOS-2333
>                 URL: https://issues.apache.org/jira/browse/MESOS-2333
>             Project: Mesos
>          Issue Type: Improvement
>          Components: security
>            Reporter: Adam B
>            Assignee: Alexander Rojas
>              Labels: authorization, filebrowser, mesosphere, security
>
> As it stands now, anybody with access to the master or slave web UI can use the filebrowser to view the contents of any attached/mounted paths on the master or slave. Currently, the attached paths include master and slave logs as well as executor/task sandboxes. While there's a chance that the master and slave logs could contain sensitive information, it's much more likely that sandboxes could contain customer data or other files that should not be globally accessible. Securing the sandboxes is the primary goal of this ticket.
> There are four filebrowser endpoints: browse, read, download, and debug. Here are some potential solutions.
> 1) We could easily provide flags that globally enable/disable each endpoint, allowing coarse-grained "access control". This might be a reasonable short-term plan. We would also want to update the web UIs to display an Access Denied error, rather than showing links that open up blank pailers.
> 2) Each master and slave handles is own authn/authz. Slaves will need to have an authenticator, and there must be a way to provide each node with credentials and ACLs, and keep these in sync across the cluster.
> 3) Filter all slave communications through the master(s), which already has credentials and ACLs. We'll have to restrict access to the filebrowser (and other?) endpoints to the (leading?) master. Then the master can perform the authentication and authorization, only passing the request on to the slave if auth succeeds.
> 3a) The slave returns the browse/read/download response back through the master. This could be a network bottleneck.
> 3b) Upon authn/z success, the master redirects the request to the appropriate slave, which will send the response directly back to the requester.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)