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.griffi...@rackspace.com <mailto:kurt.griffi...@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 <gokrokvertsk...@mirantis.com
<mailto:gokrokvertsk...@mirantis.com>>
Reply-To: OpenStack Dev <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, January 8, 2014 at 10:41 AM
To: OpenStack Dev <openstack-dev@lists.openstack.org
<mailto:openstack-dev@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.griffi...@rackspace.com
<mailto:kurt.griffi...@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.hellm...@dreamhost.com
<mailto:doug.hellm...@dreamhost.com>>
Reply-To: OpenStack Dev <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, January 7, 2014 at 6:54 AM
To: OpenStack Dev <openstack-dev@lists.openstack.org
<mailto:openstack-dev@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
<gokrokvertsk...@mirantis.com
<mailto:gokrokvertsk...@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.hellm...@dreamhost.com
<mailto:doug.hellm...@dreamhost.com>> wrote:
On Mon, Jan 6, 2014 at 2:56 PM, Georgy Okrokvertskhov
<gokrokvertsk...@mirantis.com
<mailto:gokrokvertsk...@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@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@lists.openstack.org
<mailto:OpenStack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
