Open Stack

Hi Adam,

This looks very interesting. When do you expect to have this code available
in oslo? Do you have a development guide which describes best practices for
using this authorization approach?

I think that for Pecan it will be possible to get rid of @protected wrapper
and use SecureController class as a parent. It has a method which will be
called before each controller method call. I saw Pecan was moved to
stackforge, so probably it is a good idea to talk with Pecan developers and
discuss how this part of keystone can be integrated\ supported by Pecan
framework.


On Wed, Jan 8, 2014 at 8:34 PM, Adam Young <ayoung at redhat.com> wrote:

>  We are working on cleaning up the Keystone code with an eye to Oslo and
> reuse:
>
> https://review.openstack.org/#/c/56333/
>
>
> On 01/08/2014 02:47 PM, Georgy Okrokvertskhov wrote:
>
> Hi,
>
>  Keep policy control in one place is a good idea. We can use standard
> policy approach and keep access control configuration in json file as it
> done in Nova and other projects.
>  Keystone uses wrapper function for methods. Here is a wrapper code:
> https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L111.
> Each controller method has @protected() wrapper, so a method information is
> available through python f.__name__ instead of URL parsing. It means that
> some RBAC parts anyway scattered among the code.
>
>  If we want to avoid RBAC scattered among the code we can use URL parsing
> approach and have all the logic inside hook. In pecan hook WSGI environment
> is already created and there is full access to request parameters\content.
> We can map URL to policy key.
>
>  So we have two options:
> 1. Add wrapper to each API method like all other project did
> 2. Add a hook with URL parsing which maps path to policy key.
>
>
>  Thanks
> Georgy
>
>
>
> On Wed, Jan 8, 2014 at 9:05 AM, Kurt Griffiths <
> kurt.griffiths at rackspace.com> wrote:
>
>>  Yeah, that could work. The main thing is to try and keep policy control
>> in one place if you can rather than sprinkling it all over the place.
>>
>>   From: Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>
>> Reply-To: OpenStack Dev <openstack-dev at lists.openstack.org>
>> Date: Wednesday, January 8, 2014 at 10:41 AM
>>
>> To: OpenStack Dev <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Solum][Pecan][Security] Pecan
>> SecureController vs. Nova policy
>>
>>   Hi Kurt,
>>
>>  As for WSGI middleware I think about Pecan hooks which can be added
>> before actual controller call. Here is an example how we added a hook for
>> keystone information collection:
>> https://review.openstack.org/#/c/64458/4/solum/api/auth.py
>>
>>  What do you think, will this approach with Pecan hooks work?
>>
>>  Thanks
>> Georgy
>>
>>
>> On Tue, Jan 7, 2014 at 2:25 PM, Kurt Griffiths <
>> kurt.griffiths at rackspace.com> wrote:
>>
>>>  You might also consider doing this in WSGI middleware:
>>>
>>>  Pros:
>>>
>>>    - Consolidates policy code in once place, making it easier to audit
>>>    and maintain
>>>    - Simple to turn policy on/off – just don’t insert the middleware
>>>    when off!
>>>    - Does not preclude the use of oslo.policy for rule checking
>>>    - Blocks unauthorized requests before they have a chance to touch
>>>    the web framework or app. This reduces your attack surface and can improve
>>>    performance   (since the web framework has yet to parse the request).
>>>
>>> Cons:
>>>
>>>    - Doesn't work for policies that require knowledge that isn’t
>>>    available this early in the pipeline (without having to duplicate a lot of
>>>    code)
>>>    - You have to parse the WSGI environ dict yourself (this may not be
>>>    a big deal, depending on how much knowledge you need to glean in order to
>>>    enforce the policy).
>>>    - You have to keep your HTTP path matching in sync with with your
>>>    route definitions in the code. If you have full test coverage, you will
>>>    know when you get out of sync. That being said, API routes tend to be quite
>>>    stable in relation to to other parts of the code implementation once you
>>>    have settled on your API spec.
>>>
>>> I’m sure there are other pros and cons I missed, but you can make your
>>> own best judgement whether this option makes sense in Solum’s case.
>>>
>>>   From: Doug Hellmann <doug.hellmann at dreamhost.com>
>>> Reply-To: OpenStack Dev <openstack-dev at lists.openstack.org>
>>> Date: Tuesday, January 7, 2014 at 6:54 AM
>>> To: OpenStack Dev <openstack-dev at lists.openstack.org>
>>> Subject: Re: [openstack-dev] [Solum][Pecan][Security] Pecan
>>> SecureController vs. Nova policy
>>>
>>>
>>>
>>>
>>> On Mon, Jan 6, 2014 at 6:26 PM, Georgy Okrokvertskhov <
>>> gokrokvertskhov at mirantis.com> wrote:
>>>
>>>> Hi Dough,
>>>>
>>>>  Thank you for pointing to this code. As I see you use OpenStack
>>>> policy framework but not Pecan security features. How do you implement fine
>>>> grain access control like user allowed to read only, writers and admins.
>>>> Can you block part of API methods for specific user like access to create
>>>> methods for specific user role?
>>>>
>>>
>>>  The policy enforcement isn't simple on/off switching in ceilometer, so
>>> we're using the policy framework calls in a couple of places within our API
>>> code (look through v2.py for examples). As a result, we didn't need to
>>> build much on top of the existing policy module to interface with pecan.
>>>
>>>  For your needs, it shouldn't be difficult to create a couple of
>>> decorators to combine with pecan's hook framework to enforce the policy,
>>> which might be less complex than trying to match the operating model of the
>>> policy system to pecan's security framework.
>>>
>>>  This is the sort of thing that should probably go through Oslo and be
>>> shared, so please consider contributing to the incubator when you have
>>> something working.
>>>
>>>  Doug
>>>
>>>
>>>
>>>>
>>>>  Thanks
>>>> Georgy
>>>>
>>>>
>>>> On Mon, Jan 6, 2014 at 2:45 PM, Doug Hellmann <
>>>> doug.hellmann at dreamhost.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>>  On Mon, Jan 6, 2014 at 2:56 PM, Georgy Okrokvertskhov <
>>>>> gokrokvertskhov at mirantis.com> wrote:
>>>>>
>>>>>>  Hi,
>>>>>>
>>>>>>  In Solum project we will need to implement security and ACL for
>>>>>> Solum API. Currently we use Pecan framework for API. Pecan has its own
>>>>>> security model based on SecureController class. At the same time OpenStack
>>>>>> widely uses policy mechanism which uses json files to control access to
>>>>>> specific API methods.
>>>>>>
>>>>>>  I wonder if someone has any experience with implementing security
>>>>>> and ACL stuff with using Pecan framework. What is the right way to provide
>>>>>> security for API?
>>>>>>
>>>>>
>>>>>   In ceilometer we are using the keystone middleware and the policy
>>>>> framework to manage arguments that constrain the queries handled by the
>>>>> storage layer.
>>>>>
>>>>>
>>>>> http://git.openstack.org/cgit/openstack/ceilometer/tree/ceilometer/api/acl.py
>>>>>
>>>>>  and
>>>>>
>>>>>
>>>>> http://git.openstack.org/cgit/openstack/ceilometer/tree/ceilometer/api/controllers/v2.py#n337
>>>>>
>>>>>  Doug
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>  Thanks
>>>>>>  Georgy
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>>   --
>>>> Georgy Okrokvertskhov
>>>> Technical Program Manager,
>>>> Cloud and Infrastructure Services,
>>>> Mirantis
>>>> http://www.mirantis.com
>>>> Tel. +1 650 963 9828 <%2B1%20650%20963%209828>
>>>> Mob. +1 650 996 3284 <%2B1%20650%20996%203284>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>>  --
>> Georgy Okrokvertskhov
>> Technical Program Manager,
>> Cloud and Infrastructure Services,
>> Mirantis
>> http://www.mirantis.com
>> Tel. +1 650 963 9828 <%2B1%20650%20963%209828>
>> Mob. +1 650 996 3284 <%2B1%20650%20996%203284>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>  --
> Georgy Okrokvertskhov
> Technical Program Manager,
> Cloud and Infrastructure Services,
> Mirantis
> http://www.mirantis.com
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140109/1d70bb7a/attachment-0001.html>