[
https://issues.apache.org/jira/browse/MESOS-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860187#comment-15860187
]
Greg Mann commented on MESOS-7066:
----------------------------------
[~anindya.sinha], do you think it is prohibitively complicated for users to
specify per-ACL permissive bits using {{subject=ANY,object=ANY}} and
{{subject=NONE,object=NONE}} as [~adam-mesos] suggested? This allows
specification of per-ACL permissiveness using the current protos, so strictly
speaking, no changes are necessary to use this functionality.
If we wanted to add per-ACL permissive bits, I could imagine simply adding an
{{optional bool permissive}} to each ACL message which would take priority over
the global {{permissive}} field. i.e., if a particular request is validated
against a set of ACLs and no ACLs are found to match, then we fall back to the
local per-ACL {{permissive}} bit, if set. If no local permissive bit is set,
then we fall back to the global permissive bit. This is backward-compatible
with the previous ACL format if no new ACLs have been added; an operator could
simply use their old ACL configuration during an upgrade. When the upgrade is
complete, they would be free to begin specifying per-ACL permissiveness as
desired.
However, [~anindya.sinha] I see your point regarding the benefit of a global
{{permissive=true}} during an upgrade. The corollary to this, I suppose, is
that upgrades are more difficult if {{permissive=false}} and a new ACL is added
during an upgrade. However, in that case the operator could specify an
appropriate permissive ACL for the new action in the post-upgrade ACL
configuration. This does require a bit more work from the operator.
I don't really like the idea of assuming an implicit {{permissive=true}} in the
case of an upgrade in which a new ACL has been added. Implicitly allowing
permissive authorization behavior seems like a security hole; if an operator is
going to allow all requests for a particular action, I think it's a good idea
to require them to declare that explicitly.
Ultimately, it seems to me that adding per-ACL {{permissive}} fields would be
syntactic sugar for the operator, so perhaps we should do this only if we think
it will make ACLs significantly easier to write.
> 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)
