mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Mann (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MESOS-7202) Allow 'principal.value' to be NONE in master handlers
Date Fri, 03 Mar 2017 16:19:45 GMT

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

Greg Mann updated MESOS-7202:
-----------------------------
    Description: 
The {{Principal}} type was recently introduced in libprocess to facilitate executor authentication
(MESOS-6365). Currently, we do not allow {{Principal.value}} to be {{NONE}} in the master
handler code for the following reasons:
* The master's internal structures (i.e. {{frameworks.principals}}) associate each framework
with a {{string principal}}
* The {{ReservationInfo}} and {{DiskInfo}} messages store a {{string principal}} for the purpose
of authorizing {{UNRESERVE}} and {{DESTROY}} operations

We should migrate the master's internal structures, as well as the {{ReservationInfo}} and
{{DiskInfo}} messages, to make use of an object similar to {{process::http::authentication::Principal}}.

When implementing this for {{ReservationInfo}} and {{DiskInfo}}, we should consider including
the principal in the Mesos internal message representations, while omitting the principal
from the external user-facing messages. This would eliminate the need for the user to duplicate
their principal in the contents of their {{RESERVE}}/{{CREATE}} request, when they must already
supply it in the request's authorization header.

Note that resolving this ticket will also involve removing the conditional checks within {{src/master/http.cpp}}
which currently enforce this constraint, as well as updating the master validation code.

  was:
The {{Principal}} type was recently introduced in libprocess to facilitate executor authentication
(MESOS-6365). Currently, we do not allow {{Principal.value}} to be {{NONE}} in the master
handler code for the following reasons:
* The master's internal structures (i.e. {{frameworks.principals}}) associate each framework
with a {{string principal}}
* The {{ReservationInfo}} and {{DiskInfo}} messages store a {{string principal}} for the purpose
of authorizing {{UNRESERVE}} and {{DESTROY}} operations

We should migrate the master's internal structures, as well as the {{ReservationInfo}} and
{{DiskInfo}} messages, to make use of an object similar to {{process::http::authentication::Principal}}.

When implementing this for {{ReservationInfo}} and {{DiskInfo}}, we should consider including
the principal in the Mesos internal message representations, while omitting the principal
from the external user-facing messages. This would eliminate the need for the user to duplicate
their principal in the contents of their {{RESERVE}}/{{CREATE}} request, when they must already
supply it in the request's authorization header.


> Allow 'principal.value' to be NONE in master handlers
> -----------------------------------------------------
>
>                 Key: MESOS-7202
>                 URL: https://issues.apache.org/jira/browse/MESOS-7202
>             Project: Mesos
>          Issue Type: Improvement
>            Reporter: Greg Mann
>              Labels: authentication, authorization, mesosphere, security
>
> The {{Principal}} type was recently introduced in libprocess to facilitate executor authentication
(MESOS-6365). Currently, we do not allow {{Principal.value}} to be {{NONE}} in the master
handler code for the following reasons:
> * The master's internal structures (i.e. {{frameworks.principals}}) associate each framework
with a {{string principal}}
> * The {{ReservationInfo}} and {{DiskInfo}} messages store a {{string principal}} for
the purpose of authorizing {{UNRESERVE}} and {{DESTROY}} operations
> We should migrate the master's internal structures, as well as the {{ReservationInfo}}
and {{DiskInfo}} messages, to make use of an object similar to {{process::http::authentication::Principal}}.
> When implementing this for {{ReservationInfo}} and {{DiskInfo}}, we should consider including
the principal in the Mesos internal message representations, while omitting the principal
from the external user-facing messages. This would eliminate the need for the user to duplicate
their principal in the contents of their {{RESERVE}}/{{CREATE}} request, when they must already
supply it in the request's authorization header.
> Note that resolving this ticket will also involve removing the conditional checks within
{{src/master/http.cpp}} which currently enforce this constraint, as well as updating the master
validation code.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message