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.