[openstack-dev] [openstack-common]Add support for finer-grained policy decisions

heckj heckj at mac.com
Wed Oct 10 17:11:55 UTC 2012


Mark - 

Thanks for popping this up to the list - I didn't see the reviews in openstack-common (wasn't watching).

I'm very opposed to changing policy files from declarative policy to interpreted mechanisms. There in is the road to madness and horrific complexity. I get the desire for wanting to make a seemingly simple modification to all "if/else", but it's a slippery slope from there into a full-bore interpreted world and internal variables, and the last thing we need to do is move into the world of inventing a new language (even a DSL) for authorization policies.

 It should be quite possible and not-too-terrible to create a policy that uses simple boolean logic to express this need and keep it entirely declarative, especially with the rules mechanism that's already in place.

I would, however, very much like to see a suggestion of roles and associated policies that do what Kevin needs as a suggestion for deployment. Kevin - how far down the road are you with roles and definitions for those roles of what you're doing? I'd love to get the layout to document it and include it, along with the current highly simplified global-role and come up with some structures that we can make available for suggesting how to configure openstack roles and policy files that would be useful for a wide variety of use cases.

-joe

On Oct 10, 2012, at 9:14 AM, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:
> On Wed, 2012-10-10 at 16:59 +0100, Mark McLoughlin wrote:
>> So, we're talking about this:
> [snip]
> 
> Yes, that's what I'm referring to…
> 
>> Your idea would be to make it more like:
>> 
>> +        if 'user_id' in params:
>> +            # Project admins are able to modify per-user quotas.
>> +            authorize_action(context, 'update', require='projectadmin')
>> ...
>> +        else:
>> +            # Only admins are able to modify per-project quotas.
>> +            authorize_action(context, 'update', require='fulladmin')
>> 
>> Which is just as configurable in the policy, but won't result in an
>> explosion of rules where we want to make similar distinctions. 
> 
> What I had in mind was a reorganization more like:
> 
>    authorization = authorize_action(context, 'update')
>    if authorization == 'fulladmin':
>>    elif authorization == 'projectadmin':
>> 
> Or something similar.
> 
>> It is
>> confusing, though, since you'd need to document it in the policy with
>> e.g
> 
> I have just been thinking about having a means of pre-declaring policies
> with documentation strings, similar to what we currently do with
> configuration settings; you wouldn't need to pre-declare, but it'd be
> one way to provide documentation for policies.  (Frankly, I think we
> need to document *all* of our current policy rules…)
> 
>> I'm leaning towards dropping this feature for now until we have a really
>> compelling use case for it. Now that I understand the context a bit
>> better, I think I'd be against adding this "global projectadmin role"
>> idea at all.
> 
> To be clear, I never envisioned a "global projectadmin role" either; I
> did think roles were already per-project.  I was merely using that as an
> example of where this could be useful.
> 
>> The danger with leaving it in even if there's no good use case for it is
>> that folks might find bad/confusing use cases for it :)
> 
> Heh.  Indeed, I suppose that is a danger.
> -- 
> Kevin L. Mitchell <kevin.mitchell at rackspace.com>
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list