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

Adam Young ayoung at redhat.com
Wed Jun 3 14:10:27 UTC 2015

I gave a presentation on Dynamic Policy for Access Control at the Summit.


My slides are here:

My original blog post attempted to lay out the direction:


And the Overview spec is here:

This references multiple smaller specs:

A unified policy file:

Hierarchical Roles:

Managing the Rules from a database as opposed to flat files:

Fetching the policy file from the server

Enforcing the policy via common logic in keystonemiddleware.

I've been pleased to get such a positive response;  I think most people 
agree that we need to improve the policy management in OpenStack.  This 
is not, by any means, set in stone, and all of this is still subject to 
the same review process that covers all of OpenStack.  The more I 
discuss and design, the more I've learned.

One recent discussion has driven home the fact that our policy can be 
Fragile.  We want to make it easy for people to customize policy, but 
only in certain ways.  There are parts that should be managed as part of 
the code review/engineering process, such as determining where the 
project_id exists for matching the scope of a resource. Contrast this 
with a deployer tweaking the role assignment  required in order for user 
to call that API.

Neutron uses Policy in innovative ways, and I would not want to remove 
that power.

Let's figure out what the real requirements are here, beyond what policy 
does today.  Policy is something about halfway between config and code, 
and figuring out how to manage it properly is the next step.

More information about the OpenStack-dev mailing list