[
https://issues.apache.org/jira/browse/MESOS-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859909#comment-15859909
]
Anindya Sinha edited comment on MESOS-7066 at 2/9/17 7:56 PM:
--------------------------------------------------------------
IMO as far as upgrades go when new ACLs are added, I think not having the
global {{permissive}} field (and instead only have it in each individual ACL)
would help. Basically, the same argument why upgrades are easier as far as ACLs
are concerned when global {{permissive}} is set to {{true}}.
Assume that we always have the behavior of global {{permissive}} to be {{true}}
in that case. So the actual logic is based on contents of individual ACL. If a
new ACL is introduced and that entry is missing in {{acls}} flag (as in an
upgrade potentially), then it allows all combinations to go through for that
ACL (which means it does not break the ACL functionality over an upgrade);
however, it follows the rule based on the {{action}}, local ACL's
{{permissive}} and the list of {{subject}} and {{object}} if that ACL is
specified.
However, we currently have a global {{permissive}} field and maybe an option is
to enhance it as a {{v1}} API. It is tricky to update the local ACL in {{v0}}
as in the current API since each ACL is not contained within a protobuf
envelope.
was (Author: anindya.sinha):
IMO as far as upgrades go when new ACLs are added, I think not having the
global {{permissive}} field (and instead only have it in each individual ACL)
would help.
Assume that we always have the behavior of global {{permissive}} to be {{true}}
in that case. So the actual logic is based on contents of individual ACL. If a
new ACL is introduced and that entry is missing in {{acls}} flag (as in an
upgrade potentially), then it allows all combinations to go through for that
ACL (which means it does not break the ACL functionality over an upgrade);
however, it follows the rule based on the {{action}}, local ACL's
{{permissive}} and the list of {{subject}} and {{object}} if that ACL is
specified.
However, we currently have a global {{permissive}} field and maybe an option is
to enhance it as a {{v1}} API. It is tricky to update the local ACL in {{v0}}
as in the current API since each ACL is not contained within a protobuf
envelope.
> 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)
