[
https://issues.apache.org/jira/browse/MESOS-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14314431#comment-14314431
]
Alexander Rojas commented on MESOS-2333:
----------------------------------------
(1) can be done for 0.22. What I would do is to add a flag in the master called
{{--disabled_endpoints}} which takes either a javascript blob or a file path to
a file containing a javascript blob (Just like the alc's flag). I would go for
disabled endpoints, since by default they are all enabled. Also, the json blob
allows to scale easily. There are two options then, disabled endpoints are
simply not installed (via route), or each callback takes care of its state and
returns a 403 forbidden error. I personally like the second one since it will
work well when we go for the long term approach of using
authentication/authorisation in which unauthorised users will get the 403 error.
> 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
> 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)
