[proposal] Generalized Authorizer Interface

[Alexander Rojas <al...@mesosphere.io>]

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

Re: [proposal] Generalized Authorizer Interface

[Alexander Rojas <al...@mesosphere.io>]

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 <al...@mesosphere.io> 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