[openstack-dev] [Quantum] attribute authorization

Robert Kukura rkukura at redhat.com
Mon Jul 23 22:16:36 UTC 2012


On 07/23/2012 05:10 PM, Salvatore Orlando wrote:
> I addressed the same problem on the public networks branch in gerrit in
> WIP at the moment while we finalize decision on how it should look like
> on public API.
> 
> Let me know your thoughts about the implementation. If that is good for
> you, we can just use that.

I took another look, and maybe it will do the job, which would be great!

I haven't yet made sense of all the changes, but does it boil down to
putting "enforce_read_policy: True, enforce_write_policy: True" in the
extended attribute properties?

Does this result in POST and PUT operations being rejected if the
extended attribute is present in the request message and the
authorization check fails?

Does this result in the extended attribute being silently dropped from
response message if the authorization check fails?

Finally, does this then require specifying the policy separately for
each combination of attribute and API operation? One advantage (to me at
least) of the approach I was taking is that I could simply specify

    "extension:provider_network:get": [["rule:admin_api"]],
    "extension:provider_network:view": [["rule:admin_api"]],

in the policy.json file.

-Bob

> Otherwise, I'll be extremely happy to address all your comments :)
> 
> You've already done such a lot of great work, that I think it's time for
> me to address some real issues as well!
> 
> Salvatore
> 
> On 23 July 2012 19:58, Robert Kukura <rkukura at redhat.com
> <mailto:rkukura at redhat.com>> wrote:
> 
>     Given that Salvatore and Sumit were both concerned about the plugins
>     doing the authorization for provider network extended attributes (see
>     patch set 5 of https://review.openstack.org/#/c/9069/), I've been
>     working on a very simple mechanism to move those policy checks into the
>     core. This mechanism can be used for core attributes as well as extended
>     attributes that require specific authorization to be set or viewed.
> 
>     The resource attributes map (see quantum/api/v2/attributes.py) currently
>     has boolean properties called allow_post, allow_put, and is_visible that
>     control whether an attribute can be set via create, set via update, or
>     viewed, respectively. My proposed approach is that each of these three
>     properties can still be a boolean, but if it is instead a string, that
>     string is passed to the policy.check function as the name of an action,
>     and the result of the check is used as the boolean would have been used.
> 
>     Please let me know ASAP whether or not you feel this approach is
>     acceptable, or if you've got any questions or better (simple) ideas. I
>     hope to have it implemented and included in the next provider-network BP
>     patch later today.
> 
>     Thanks,
> 
>     -Bob
> 
> 





More information about the OpenStack-dev mailing list