[ 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)