[openstack-dev] [keystone] [nova] [oslo] [cross-project] Dynamic Policy

Adam Young ayoung at redhat.com
Fri Jun 5 15:43:44 UTC 2015


On 06/03/2015 01:43 PM, Sean Dague wrote:
> On 06/03/2015 10:10 AM, Adam Young wrote:
>> I gave a presentation on Dynamic Policy for Access Control at the Summit.
>>
>> https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/dynamic-policy-for-access-control
>>
>>
>> My slides are here:
>> http://adam.younglogic.com/presentations/dynamic_policy.pp.pdf
>>
>>
>> My original blog post attempted to lay out the direction:
>>
>> http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/
>>
>> And the Overview spec is here:
>> https://review.openstack.org/#/c/147651/
>>
>>
>> This references multiple smaller specs:
>>
>> A unified policy file:
>> https://review.openstack.org/134656
> The unified policy file, as an actual single file is part of this
> process which I'm concerned isn't workable unless all OpenStack
> components are upgraded lock step, which is actually a situation we want
> to do less of, not more of.
Right.  What we really need is a set of common rules that the projects 
all agree on as the start of project specific policy.

A unified policy file is not maintainable long term if there are going 
to be a huge number of microversion changes.
We'll have strange dependencies where we need to get a change into the 
unified file first, but then the code that goes
in to Nova gets modified enough so that the policy is no longer valid.

I still think the unified policy file process is essential to working 
out the differences between the projects.

Perhaps a better starting point is a common policy header file, assumed 
to be applied prior to the default policy from each of the projects?

>
> Assume that Keystone git tree owns that file. Nova adds an API via
> microversions for an intermediate milestone that adds new policy in.
> Deployers CD this version out, leaving Keystone at the previous release
> version. Now Nova has code out there that requires policy which doesn't
> exist. The policy at some level is really linked to the code.
>
> In a world of microversions this is now a lot more like database schema,
> because big bang API changes are a thing of the past (at least on the
> Nova side). (Note: I'm working up some more general explanation of that
> whole model shortly, part of our comms plan out of summit).

So...I think Microversions are the heart of what we need to address.  It 
took me a while, and too much for an email, to think through it, so I 
wrote it up here:

http://adam.younglogic.com/2015/06/dyn-policy-microversions/

So long as the unified policy file is turned back into a Nova managed 
policy file, I think we meet your concerns.


>
> 	-Sean
>




More information about the OpenStack-dev mailing list