[
https://issues.apache.org/jira/browse/MESOS-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rojas updated MESOS-2333:
-----------------------------------
Assignee: Alexander Rojas
> 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)
