[jira] [Comment Edited] (MESOS-5155) Consolidate authorization actions for quota.

["Zhitao Li (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241500#comment-15241500 ] 

Zhitao Li edited comment on MESOS-5155 at 4/14/16 4:59 PM:
-----------------------------------------------------------

READ_QUOTA is not protected by ACL today. I haven't seen consistent design or document about additional authorization beyond simple authentication about readonly http endpoints. Also, some or all quota information could be inferred from either "monitor/snapshop" or "offers" endpoints too, so we would also need to protect those endpoints if reading quota is considered sensitive. I'm not saying it's not useful, but it should be addressed in a larger project with consistent design.

So, my initial proposal matches your "OK" option while my alternative proposal matches the "Good" option. I assume you want to make the operators move faster in this deprecation cycle. I'm fine with that idea.

I'll start working on this today/tomorrow.


was (Author: zhitao):
READ_QUOTA is not protected by ACL today. I haven't seen consistent design or document about additional authorization and authentication about readonly http endpoints today.

So, my initial proposal matches your "OK" option while my alternative proposal matches the "Good" option. I assume you want to make the operators move faster in this deprecation cycle. I'm fine with that idea.

I'll start working on this today/tomorrow.

> Consolidate authorization actions for quota.
> --------------------------------------------
>
>                 Key: MESOS-5155
>                 URL: https://issues.apache.org/jira/browse/MESOS-5155
>             Project: Mesos
>          Issue Type: Improvement
>            Reporter: Alexander Rukletsov
>            Assignee: Zhitao Li
>              Labels: mesosphere
>
> We should have just a single authz action: {{UPDATE_QUOTA_WITH_ROLE}}. It was a mistake in retrospect to introduce multiple actions.
> Actions that are not symmetrical are register/teardown and dynamic reservations. The way they are implemented in this way is because entities that do one action differ from entities that do the other. For example, register framework is issued by a framework, teardown by an operator. What is a good way to identify a framework? A role it runs in, which may be different each launch and makes no sense in multi-role frameworks setup or better a sort of a group id, which is its principal. For dynamic reservations and persistent volumes, they can be both issued by frameworks and operators, hence similar reasoning applies. 
> Now, quota is associated with a role and set only by operators. Do we need to care about principals that set it? Not that much. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)