[ 
https://issues.apache.org/jira/browse/MESOS-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam B updated MESOS-4956:
--------------------------
    Description: 
To protect access (authz) to master/agent logs as well as executor sandboxes, 
we need authentication on the /files endpoints.

Adding HTTP authentication to these endpoints is a bit complicated since they 
are defined in code that is shared by the master and agent.

While working on MESOS-4850, it became apparent that since our tests use the 
same instance of libprocess for both master and agent, different default 
authentication realms must be used for master/agent so that HTTP authentication 
can be independently enabled/disabled for each.

We should establish a mechanism for making an endpoint authenticated that 
allows us to:
1) Install an endpoint like {{/files}}, whose code is shared by the master and 
agent, with different authentication realms for the master and agent
2) Avoid hard-coding a default authentication realm into libprocess, to permit 
the use of different authentication realms for the master and agent and to keep 
application-level concerns from leaking into libprocess

Another option would be to use a single default authentication realm and always 
enable or disable HTTP authentication for *both* the master and agent in tests. 
However, this wouldn't allow us to test scenarios where HTTP authentication is 
enabled on one but disabled on the other.

  was:
In addition to the endpoints addressed by MESOS-4850, the following endpoints 
would also benefit from HTTP authentication:
* {{/files/*}}
* {{/profiler/*}}
* {{/logging/toggle}}
* {{/metrics/snapshot}}
* {{/monitor/statistics}}
* {{/system/stats.json}}


Adding HTTP authentication to these endpoints is a bit more complicated: some 
endpoints are defined at the libprocess level, while others are defined in code 
that is shared by the master and agent.

While working on MESOS-4850, it became apparent that since our tests use the 
same instance of libprocess for both master and agent, different default 
authentication realms must be used for master/agent so that HTTP authentication 
can be independently enabled/disabled for each.

We should establish a mechanism for making an endpoint authenticated that 
allows us to:
1) Install an endpoint like {{/files}}, whose code is shared by the master and 
agent, with different authentication realms for the master and agent
2) Avoid hard-coding a default authentication realm into libprocess, to permit 
the use of different authentication realms for the master and agent and to keep 
application-level concerns from leaking into libprocess

Another option would be to use a single default authentication realm and always 
enable or disable HTTP authentication for *both* the master and agent in tests. 
However, this wouldn't allow us to test scenarios where HTTP authentication is 
enabled on one but disabled on the other.


> Add authentication to /files endpoints
> --------------------------------------
>
>                 Key: MESOS-4956
>                 URL: https://issues.apache.org/jira/browse/MESOS-4956
>             Project: Mesos
>          Issue Type: Improvement
>          Components: HTTP API
>            Reporter: Greg Mann
>            Assignee: Greg Mann
>              Labels: authentication, http, mesosphere, security
>
> To protect access (authz) to master/agent logs as well as executor sandboxes, 
> we need authentication on the /files endpoints.
> Adding HTTP authentication to these endpoints is a bit complicated since they 
> are defined in code that is shared by the master and agent.
> While working on MESOS-4850, it became apparent that since our tests use the 
> same instance of libprocess for both master and agent, different default 
> authentication realms must be used for master/agent so that HTTP 
> authentication can be independently enabled/disabled for each.
> We should establish a mechanism for making an endpoint authenticated that 
> allows us to:
> 1) Install an endpoint like {{/files}}, whose code is shared by the master 
> and agent, with different authentication realms for the master and agent
> 2) Avoid hard-coding a default authentication realm into libprocess, to 
> permit the use of different authentication realms for the master and agent 
> and to keep application-level concerns from leaking into libprocess
> Another option would be to use a single default authentication realm and 
> always enable or disable HTTP authentication for *both* the master and agent 
> in tests. However, this wouldn't allow us to test scenarios where HTTP 
> authentication is enabled on one but disabled on the other.



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

Reply via email to