Open Stack

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
>> Mob. +1 650 996 3284
>>
>> _______________________________________________
>> 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
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140108/91e9e62f/attachment.html>