mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam B (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (MESOS-7066) Allow permissive bit to be set for individual acls (in addition to the global level)
Date Thu, 09 Feb 2017 06:17:41 GMT

    [ 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)

Mime
View raw message