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