[jira] [Commented] (MESOS-7066) Allow permissive bit to be set for individual acls (in addition to the global level)
[
https://issues.apache.org/jira/browse/MESOS-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872702#comment-15872702
]
Yan Xu commented on MESOS-7066:
---
Oh yes I guess it would.
> 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)
[jira] [Commented] (MESOS-7066) Allow permissive bit to be set for individual acls (in addition to the global level)
[
https://issues.apache.org/jira/browse/MESOS-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872691#comment-15872691
]
Greg Mann commented on MESOS-7066:
--
[~xujyan] if I understand the situation you mentioned correctly, the operator
could do this:
* Set the global permissive bit to true
* In the specification of the single ACL that you want to behave as
non-permissive, provide {{subject=ANY, object=NONE}} as the _last_ item in its
list. This will have the effect of {{permissive=false}} for that ACL only.
Would that satisfy the use case you're thinking of?
> 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)
[jira] [Commented] (MESOS-7066) Allow permissive bit to be set for individual acls (in addition to the global level)
[
https://issues.apache.org/jira/browse/MESOS-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872638#comment-15872638
]
Yan Xu commented on MESOS-7066:
---
I may be misunderstanding something but I thought it's not about allowing
people to use a {{permissive}} bit as syntactical sugar for
{{subject=ANY,object=ANY}} and {{subject=NONE,object=NONE}} but rather, if I,
an operator, only care about one ACL in a non-permissive form, I shouldn't have
to fill in all possible ACLs on the process today and watch closely for all
future additions?
> 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)
[jira] [Commented] (MESOS-7066) Allow permissive bit to be set for individual acls (in addition to the global level)
[
https://issues.apache.org/jira/browse/MESOS-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (MESOS-7066) Allow permissive bit to be set for individual acls (in addition to the global level)
[
https://issues.apache.org/jira/browse/MESOS-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859909#comment-15859909
]
Anindya Sinha commented on MESOS-7066:
--
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)
[jira] [Commented] (MESOS-7066) Allow permissive bit to be set for individual acls (in addition to the global level)
[
https://issues.apache.org/jira/browse/MESOS-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15859087#comment-15859087
]
Adam B commented on MESOS-7066:
---
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)
