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
Hierarchical Roles:
https://review.openstack.org/125704
Managing the Rules from a database as opposed to flat files:
https://review.openstack.org/184926
Fetching the policy file from the server
https://review.openstack.org/134655
Enforcing the policy via common logic in keystonemiddleware.
https://review.openstack.org/133480
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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
