Open Stack

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 <mailto: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
>     <mailto:gokrokvertskhov at mirantis.com>>
>     Reply-To: OpenStack Dev <openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>
>     Date: Wednesday, January 8, 2014 at 10:41 AM
>
>     To: OpenStack Dev <openstack-dev at lists.openstack.org
>     <mailto: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
>     <mailto: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
>         <mailto:doug.hellmann at dreamhost.com>>
>         Reply-To: OpenStack Dev <openstack-dev at lists.openstack.org
>         <mailto:openstack-dev at lists.openstack.org>>
>         Date: Tuesday, January 7, 2014 at 6:54 AM
>         To: OpenStack Dev <openstack-dev at lists.openstack.org
>         <mailto: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
>         <mailto: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
>             <mailto:doug.hellmann at dreamhost.com>> wrote:
>
>
>
>
>                 On Mon, Jan 6, 2014 at 2:56 PM, Georgy Okrokvertskhov
>                 <gokrokvertskhov at mirantis.com
>                 <mailto: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
>                     <mailto: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
>                 <mailto: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 <http://www.mirantis.com/>
>             Tel. +1 650 963 9828 <tel:%2B1%20650%20963%209828>
>             Mob. +1 650 996 3284 <tel:%2B1%20650%20996%203284>
>
>             _______________________________________________
>             OpenStack-dev mailing list
>             OpenStack-dev at lists.openstack.org
>             <mailto: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
>         <mailto: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 <http://www.mirantis.com/>
>     Tel. +1 650 963 9828 <tel:%2B1%20650%20963%209828>
>     Mob. +1 650 996 3284 <tel:%2B1%20650%20996%203284>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto: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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140108/c78ac746/attachment.html>