[openstack-dev] Dynamic Policy

Henry Nash henryn at linux.vnet.ibm.com
Wed Nov 19 12:57:04 UTC 2014

Hi Adam,

So a comprehensive write-up...although I'm not sure we have made the case for why we need a complete rewrite of how policy is managed.  We seemed to have lept into a solution without looking at other possible solutions to the problems we are trying to solve.  Here's a start at an alternative approach:

Problem 1: The current services don't use the centralised policy store/fetch of keystone, meaning that a) policy file management is hard, and b) we can't support the policy-per-endpoint style of working
Solution: Let's get the other services using it!  No code changes required in Keytsone.  The fact that we haven't succeeded before, just means we haven't tried hard enough.

Problem 2: Different domains want to be able to create their own "roles" which are more meaningful to their users...but our "roles" are global and are directly linked to the rules in the policy file - something only a cloud operator is going to want to own.
Solution: Have some kind of domain-scoped role-group (maybe just called "domain-roles"?) that a domain owner can define, that maps to a set of underlying roles that a policy file understands (see: https://review.openstack.org/#/c/133855/). [As has been pointed out, what we are really doing with this is finally doing real RBAC, where what we call roles today are really capabilities and domain-roles are really just roles].  As this evolves, cloud providers could slowly migrate to the position where each service API is effectively a role (i.e. a capability) and at the domain level there exists the "abstraction that makes sense for the users of that domain" into the underlying capabilities. No code changes...this just uses policy files as they are today (plus domain-groups) - and tokens as they are too. And I think that level of functionality would satisfy a lot of people. Eventually (as pointed out by samuelmz) the policy "file" could even simply become the definition of the service capabilities (and whether each capability is "open", "closed" or "is a role")...maybe just registered and stored in the service entity the keystone DB (allowing dynamic service registration). My point being, that we really didn't require much code change (nor really any conceptual changes) to get to this end point...and certainly no rewriting of policy/token formats etc.  [In reality, this last point would cause problems with token size (since a broad admin capability would need a lot of capabilities), so some kind a collections of capabilities would be required.]

Problem 3: A cloud operator wants to be able to enable resellers to white label her services (who in turn may resell to others) - so needs some kind of inheritance model so that service level agreements can be supported by policy (e.g. let the reseller give the support expert from the cloud provider have access to their projects).
Solution: We already have hierarchical inheritance in the works...so that we would allow a reseller to assign roles to a user/group from the parent onto their own domain/project. Further, domain-roles are just another thing that can (optionally) be inherited and used in this fashion.

My point about all the above is that I think while what you have laid out is a great set of steps....I don't think we have conceptual agreement as to whether that path is the only way we could go to solve out problems.

On 18 Nov 2014, at 23:40, Adam Young <ayoung at redhat.com> wrote:

> There is a lot of discussion about policy.  I've attempted to pull the majority of the work into a single document that explains the process in a step-by-step manner:
> http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/
> Its really long, so I won't bother reposting the whole article here.  Instead, I will post the links to the topic on Gerrit.
> https://review.openstack.org/#/q/topic:dynamic-policy,n,z
> There is one additional review worth noting:
> https://review.openstack.org/#/c/133855/
> Which is for "private groups of roles"  specific to a domain.  This is related, but not part of the critical path for the things I wrote above.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/bf75e3e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/bf75e3e4/attachment.pgp>

More information about the OpenStack-dev mailing list