[jira] [Updated] (MESOS-2333) Securing Sandboxes via Filebrowser Access Control
[ https://issues.apache.org/jira/browse/MESOS-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Quarfot Nielsen updated MESOS-2333: -- Sprint: Mesosphere Q1 Sprint 3 - 2/20, Mesosphere Q1 Sprint 4 - 3/6, Mesosphere Q1 Sprint 5 - 3/20, Mesosphere Q1 Sprint 6 - 4/3 (was: Mesosphere Q1 Sprint 3 - 2/20, Mesosphere Q1 Sprint 4 - 3/6, Mesosphere Q1 Sprint 5 - 3/20) 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)
[jira] [Updated] (MESOS-2333) Securing Sandboxes via Filebrowser Access Control
[ https://issues.apache.org/jira/browse/MESOS-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Quarfot Nielsen updated MESOS-2333: -- Sprint: Mesosphere Q1 Sprint 3 - 2/20, Mesosphere Q1 Sprint 4 - 3/6, Mesosphere Q1 Sprint 5 - 3/20 (was: Mesosphere Q1 Sprint 3 - 2/20, Mesosphere Q1 Sprint 4 - 3/6) 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)
[jira] [Updated] (MESOS-2333) Securing Sandboxes via Filebrowser Access Control
[ https://issues.apache.org/jira/browse/MESOS-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Quarfot Nielsen updated MESOS-2333: -- Sprint: Mesosphere Q1 Sprint 3 - 2/20, Mesosphere Q1 Sprint 3 - 3/6 (was: Mesosphere Q1 Sprint 3 - 2/20) 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)
[jira] [Updated] (MESOS-2333) Securing Sandboxes via Filebrowser Access Control
[ https://issues.apache.org/jira/browse/MESOS-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Quarfot Nielsen updated MESOS-2333: -- Target Version/s: 0.23.0 (was: 0.22.0) 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)
[jira] [Updated] (MESOS-2333) Securing Sandboxes via Filebrowser Access Control
[ 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)
[jira] [Updated] (MESOS-2333) Securing Sandboxes via Filebrowser Access Control
[ https://issues.apache.org/jira/browse/MESOS-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rojas updated MESOS-2333: --- Shepherd: Till Toenshoff 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)
[jira] [Updated] (MESOS-2333) Securing Sandboxes via Filebrowser Access Control
[ https://issues.apache.org/jira/browse/MESOS-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-2333: -- Sprint: Mesosphere Q1 Sprint 3 - 2/20 Target Version/s: 0.22.0 Labels: authorization filebrowser mesosphere security (was: authorization filebrowser security) 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)
