Hi Everyone, After looking at your comments and doing some extra design we have updated the proposal for the Authorized Interface. Among the main changes is to remove the attributes of all the parameters and making the actions an enum. The full text can be found here:
https://docs.google.com/document/d/1-XARWJFUq0r_TgRHz_472NvLZNjbqE4G8c2JL44OSMQ/edit#heading=h.o4fbpp2hx411 <https://docs.google.com/document/d/1-XARWJFUq0r_TgRHz_472NvLZNjbqE4G8c2JL44OSMQ/edit#heading=h.o4fbpp2hx411> Among the most recurrent question is how the change will be experience by users (operators and framework developers). So from their perspective, things won’t change unless using custom authorizers, and then only operators will notify one change: the load of the plugin for the custom authorizer. I would like to listen from you guys on the proposal for recommendations in case we missed something. Thanks, Alexander Rojas > On 06 Jul 2015, at 15:42, Alexander Rojas <[email protected]> wrote: > > Hi everyone, > > The current mesos::Authorizer API has one method for each of the actions > supported (Register Framework, Launch Task and Shutdown Framework), and each > of > these actions define the objects on which they operate. > > Currently, if the Authorizer needs to be extended by adding a new action, it > is > necessary to modify the mesos::Authorizer interface and all its > implementations > (currently only mesos::LocalAuthorizer), and add a new nested message to the > ACL > message in mesos.proto. > > I want to propose a new version of the mesos::Authorizer interface which > allows > implementations to offer any set of custom actions. It also hides > implementation > details of how authorization is performed with the goal to allow for different > authorization backends. > > The updated interface will look then like this: > > class Authorizer { > public: > virtual ~Authorizer() {} > > virtual process::Future<bool> authorize( > const Option<Principal>& principal, > const Action& action, > const Option<Object>& object) = 0; > > protected: > Authorizer() {} > }; > > Where Principal, Action and Object are protocol buffer generated objects > defined > as: > > message Principal { > required string value = 1; > repeated Parameter attributes = 2; > } > > message Action { > required string value = 1; > repeated Parameter attributes = 2; > } > > message Object { > required string value = 1; > repeated Parameter attributes = 2; > } > > The full text of the proposal can be found at > https://docs.google.com/document/d/1-XARWJFUq0r_TgRHz_472NvLZNjbqE4G8c2JL44OSMQ/edit > > Note that Mesos users which defined ACLs through the --acls flags should not > notice any change in behavior after the change. > > We’d love to get people’s feedback so we can move forward! > > Thanks, > Alexander Rojas
