[
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 this part of the improvement is
blocked by MESOS-7203 because of the authorization-without-authentication
problem.)
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.
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.
> 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 this
> part of the improvement is blocked by MESOS-7203 because of the
> authorization-without-authentication problem.)
> 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)
