Open Stack

Georgy,

Pecan hook functions (http://pecan.readthedocs.org/en/latest/hooks.html) are passed a `state` argument, which has a couple of attributes you can make use of.  Starting at the `before` hook, you have access to `state.controller`, which is the @pecan.expose() decorated controller/function that pecan discovered in its routing algorithm (if any):

class MyHook(pecan.hooks.PecanHook):

    def before(self, state):
        assert isinstance(state.request, webob.Request)
        assert state.controller.__func__ is MyController.index.__func__  # for examples’ sake, to illustrate the *type* of the controller attribute.  This could be False, depending on the URL path :)

Important to note is that `state.controller` will be `None` in the `on_route` hook, because the routing of the path to controller hasn’t actually happened at that point.

---
Ryan Petrello
Senior Developer, DreamHost
ryan.petrello at dreamhost.com

On Jan 9, 2014, at 6:44 PM, Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com> wrote:

> Hi Rayan,
> 
> Thank you for sharing your view on SecureController. That is always good to hear info from the developers who are deeply familiar with the code base.
> 
> I like an idea with hooks. If we go this path, we will need to have an information about a method of a particular controller which will be called if authorization is successful. In current keystone implementation this is done by wrapper which knows the actual method name it wraps. This allows one to write simple rules for specific methods like  "identity:get_policy": "rule:admin_required",
> 
> Do you know if you are inside hook code is there a way to obtain information about router and method which will be called after hook?
> 
> Thanks
> Georgy
> 
> 
> On Thu, Jan 9, 2014 at 2:48 PM, Ryan Petrello <ryan.petrello at dreamhost.com> wrote:
> As a Pecan developer, I’ll chime in and say that I’m actually *not* a fan of SecureController and its metaclass approach.  Maybe it’s just too magical for my taste.  I’d give a big thumbs up to an approach that involves utilizing pecan’s hooks.  Similar to Kurt’s suggestion with middleware, they give you the opportunity to hook in security *before* the controller call, but they avoid the nastiness of parsing the WSGI environ by hand and writing code that duplicates pecan’s route-to-controller resolution.
> 
> ---
> Ryan Petrello
> Senior Developer, DreamHost
> ryan.petrello at dreamhost.com
> 
> On Jan 9, 2014, at 3:04 PM, Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com> wrote:
> 
> > 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
> >> 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
> >>
> >>
> >> _______________________________________________
> >> 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