[jira] [Comment Edited] (MESOS-7066) Allow permissive bit to be set for individual acls (in addition to the global level)

["Adam B (JIRA)" <ji...@apache.org>]

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

Adam B edited comment on MESOS-7066 at 2/9/17 6:17 AM:
-------------------------------------------------------

Good point. I've seen other ACL schemas with permissive bits at each level. And others that just deny by default and require explicit allowances, which can then be denied based on other criteria (deny-allow-deny schemas).
I recall previous reasoning that with the global permissive=false, we can simulate a per-action permissive=true by adding a single ACL entry for that action where subject=ANY and object=ANY. And the reverse with subject/object=NONE to override a global permissive=true. But maybe a per-action permissive bit would be easier to use?
But regardless, we need a better story around "secure" vs. "painless" upgrades when new ACLs are introduced. Should these new ACLs be permissive/not based on the previously set ACLs' global permissive bit? Or should we allow a special flag on upgrade that defines whether to allow/deny the new ACLs by default? We ran into similar upgrade issues that caused us to split the {{-authenticate_http}} flag into {{-authenticate_http_readwrite}} (the previously authenticated endpoints) and {{-authenticate_http_readonly}} (the newly authenticated endpoints).


was (Author: adam-mesos):
Good point. I've seen other ACL schemas with permissive bits at each level. And others that just deny by default and require explicit allowances, which can then be denied based on other criteria (deny-allow-deny schemas).
I recall previous reasoning that with the global permissive=false, we can simulate a per-action permissive=true by adding a single ACL entry for that action where subject=ANY and object=ANY. And the reverse with subject/object=NONE to override a global permissive=true. But maybe a per-action permissive bit would be easier to use?
But regardless, we need a better story around "secure" vs. "painless" upgrades when new ACLs are introduced. Should these new ACLs be permissive/not based on the previously set ACLs' global permissive bit? Or should we allow a special flag on upgrade that defines whether to allow/deny the new ACLs by default? We ran into similar upgrade issues that caused us to split the {{--authenticate_http}} flag into {{--authenticate_http_readwrite}} (the previously authenticated endpoints) and {{--authenticate_http_readonly}} (the newly authenticated endpoints).

> Allow permissive bit to be set for individual acls (in addition to the global level)
> ------------------------------------------------------------------------------------
>
>                 Key: MESOS-7066
>                 URL: https://issues.apache.org/jira/browse/MESOS-7066
>             Project: Mesos
>          Issue Type: Improvement
>          Components: security
>            Reporter: Anindya Sinha
>            Assignee: Adam B
>            Priority: Minor
>              Labels: acl
>
> Currently, while defining ACLs for master or agents, there is a boolean field  {{permissive}} that can be set on the global level that applies to all acls.
> It defines the behavior when no ACL matches to the request made. If set to true (which is the default) it will allow by default all non-matching requests, if set to false it will reject all non-matching requests.
> We should consider supporting a local {{permissive}} field specific to each ACL which would override the global {{permissive}} field if the local {{permissive}} field is set.
> The use case is that if support for a new ACL is added to master or agent, and a cluster uses the global {{permissive}} field set to {{false}}, that would imply that the authorization for the newly added ACL shall fail unless the operator adds the corresponding entry for the newly added ACL, which leads to a upgrade issue.
> If we have both the global as well as local {{permissive}} bit, then the global {{permissive}} bit can be set to {{true}}, whereas the local {{permissive}} bit can be set to true or false based on the use case. With this approach, it would not be mandatory to add an entry for the new ACL entry unless the operator chooses to do so.
> That obviously also leads to the fact that maybe we should not have the global {{permissive}} bit in the first place.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)