[openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy

Georgy Okrokvertskhov gokrokvertskhov at mirantis.com
Wed Jan 8 19:47:12 UTC 2014


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
>>> 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
>
> _______________________________________________
> 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/9aba3e1d/attachment.html>


More information about the OpenStack-dev mailing list