On 06/04/2015 05:49 PM, Morgan Fainberg wrote:
Hi Everyone!
I've been reading through this thread and have had some conversations
along the side and wanted to jump in to distill out what I think are
the key points we are trying to address here. I'm going to outline
about 4 items that seem to
Hi Everyone!
I've been reading through this thread and have had some conversations along
the side and wanted to jump in to distill out what I think are the key
points we are trying to address here. I'm going to outline about 4 items
that seem to make sense to me regarding the evolution of policy.
On 06/04/2015 01:03 PM, Adam Young wrote:
On 06/04/2015 09:40 AM, Sean Dague wrote:
So I feel like I understand the high level dynamic policy end game. I
feel like what I'm proposing for policy engine with encoded defaults
doesn't negatively impact that. I feel there is a middle chunk where
and counterintuitive?
Guang
-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: Thursday, June 04, 2015 10:16 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting
On 06/04/2015 01:03 PM, Adam Young wrote
On 06/04/2015 09:40 AM, Sean Dague wrote:
So I feel like I understand the high level dynamic policy end game. I
feel like what I'm proposing for policy engine with encoded defaults
doesn't negatively impact that. I feel there is a middle chunk where
perhaps we've got different concerns or
On 06/04/2015 09:40 AM, Sean Dague wrote:
Is there some secret dragon I'm missing here?
No. But it is a significant bit of coding to do; you would need to
crawl every API and make sure you hit every code path that could enforce
policy.
Um, I don't understand that.
I'm saying that you'd
Inline.
On Thu, Jun 4, 2015 at 6:40 AM, Sean Dague s...@dague.net wrote:
On 06/04/2015 08:52 AM, Adam Young wrote:
On 06/04/2015 06:32 AM, Sean Dague wrote:
On 06/03/2015 08:40 PM, Tim Hinrichs wrote:
As long as there's some way to get the *declarative* policy from the
system (as a data
On 06/04/2015 12:12 PM, Tim Hinrichs wrote:
Inline.
On Thu, Jun 4, 2015 at 6:40 AM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
On 06/04/2015 08:52 AM, Adam Young wrote:
On 06/04/2015 06:32 AM, Sean Dague wrote:
On 06/03/2015 08:40 PM, Tim Hinrichs wrote:
On 06/03/2015 08:40 PM, Tim Hinrichs wrote:
As long as there's some way to get the *declarative* policy from the
system (as a data file or as an API call) that sounds fine. But I'm
dubious that it will be easy to keep the API call that returns the
declarative policy in sync with the actual
On 06/04/2015 01:16 PM, Sean Dague wrote:
It gets overwritten by the central store.
And you are wrong, that gives me what I want, because we can emit a
WARNING in the logs if the patch is something crazy. The operators will
see it, and be able to fix it later.
I'm not trying to prevent people
On 06/04/2015 06:32 AM, Sean Dague wrote:
On 06/03/2015 08:40 PM, Tim Hinrichs wrote:
As long as there's some way to get the *declarative* policy from the
system (as a data file or as an API call) that sounds fine. But I'm
dubious that it will be easy to keep the API call that returns the
On 06/04/2015 08:52 AM, Adam Young wrote:
On 06/04/2015 06:32 AM, Sean Dague wrote:
On 06/03/2015 08:40 PM, Tim Hinrichs wrote:
As long as there's some way to get the *declarative* policy from the
system (as a data file or as an API call) that sounds fine. But I'm
dubious that it will be
Excerpts from Sean Dague's message of 2015-06-03 13:34:11 -0400:
On 06/03/2015 12:10 PM, Tim Hinrichs wrote:
I definitely buy the idea of layering policies on top of each other.
But I'd worry about the long-term feasibility of putting default
policies into code mainly because it ensures
As long as there's some way to get the *declarative* policy from the system
(as a data file or as an API call) that sounds fine. But I'm dubious that
it will be easy to keep the API call that returns the declarative policy in
sync with the actual code that implements that policy.
Tim
On Wed,
On 06/02/2015 06:27 PM, Morgan Fainberg wrote:
On Tue, Jun 2, 2015 at 12:09 PM, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
Since this a cross project concern, sending it out to the wider
mailing list:
We have a sub-effort in Keystone to do better access
I definitely buy the idea of layering policies on top of each other. But
I'd worry about the long-term feasibility of putting default policies into
code mainly because it ensures we'll never be able to provide any tools
that help users (or other services like Horizon) know what the effective
On 06/03/2015 06:47 AM, Sean Dague wrote:
Where I get fuzzy on what I've read / discussed on Dynamic Policy right
now is the fact that every API call is going to need another round trip
to Keystone for a policy check (which would be db calls in keystone?)
Which, maybe is fine, but it seems like
On 06/03/2015 12:10 PM, Tim Hinrichs wrote:
I definitely buy the idea of layering policies on top of each other.
But I'd worry about the long-term feasibility of putting default
policies into code mainly because it ensures we'll never be able to
provide any tools that help users (or other
Since this a cross project concern, sending it out to the wider mailing
list:
We have a sub-effort in Keystone to do better access control policy (not
the Neutron or Congress based policy efforts).
I presented on this at the summit, and the effort is under full swing.
We are going to set
On Tue, Jun 2, 2015 at 12:09 PM, Adam Young ayo...@redhat.com wrote:
Since this a cross project concern, sending it out to the wider mailing
list:
We have a sub-effort in Keystone to do better access control policy (not
the Neutron or Congress based policy efforts).
I presented on this
20 matches
Mail list logo
