[ https://issues.apache.org/jira/browse/MESOS-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611450#comment-14611450 ]
Adam B commented on MESOS-2333: ------------------------------- Re-resolving, since it was previously Closed:Fixed by the fix for MESOS-2620, but was reopened due to a recent JIRA mishap. > 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)