Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy
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.petre...@dreamhost.com On Jan 9, 2014, at 6:44 PM, Georgy Okrokvertskhov gokrokvertsk...@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.petre...@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.petre...@dreamhost.com On Jan 9, 2014, at 3:04 PM, Georgy Okrokvertskhov gokrokvertsk...@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 ayo...@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.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 Reply-To: OpenStack Dev openstack-dev@lists.openstack.org Date: Wednesday, January 8, 2014 at 10:41 AM To: OpenStack Dev openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy Hi Kurt, As for WSGI
Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy
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 ayo...@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.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 Reply-To: OpenStack Dev openstack-dev@lists.openstack.org Date: Wednesday, January 8, 2014 at 10:41 AM To: OpenStack Dev 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 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 Reply-To: OpenStack Dev openstack-dev@lists.openstack.org Date: Tuesday, January 7, 2014 at 6:54 AM To: OpenStack Dev 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 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
Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy
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.petre...@dreamhost.com On Jan 9, 2014, at 3:04 PM, Georgy Okrokvertskhov gokrokvertsk...@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 ayo...@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.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 Reply-To: OpenStack Dev openstack-dev@lists.openstack.org Date: Wednesday, January 8, 2014 at 10:41 AM To: OpenStack Dev 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 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 Reply-To: OpenStack Dev openstack-dev@lists.openstack.org Date: Tuesday, January 7, 2014 at 6:54 AM To: OpenStack Dev
Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy
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.petre...@dreamhost.comwrote: 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.petre...@dreamhost.com On Jan 9, 2014, at 3:04 PM, Georgy Okrokvertskhov gokrokvertsk...@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 ayo...@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.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 Reply-To: OpenStack Dev openstack-dev@lists.openstack.org Date: Wednesday, January 8, 2014 at 10:41 AM To: OpenStack Dev 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 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
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 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 Reply-To: OpenStack Dev openstack-dev@lists.openstack.org Date: Tuesday, January 7, 2014 at 6:54 AM To: OpenStack Dev 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 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 wrote: On Mon, Jan 6, 2014 at 2:56 PM, Georgy Okrokvertskhov 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 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 -- 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo
Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy
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.commailto:gokrokvertsk...@mirantis.com Reply-To: OpenStack Dev openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, January 8, 2014 at 10:41 AM To: OpenStack Dev openstack-dev@lists.openstack.orgmailto: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.commailto: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.commailto:doug.hellm...@dreamhost.com Reply-To: OpenStack Dev openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, January 7, 2014 at 6:54 AM To: OpenStack Dev openstack-dev@lists.openstack.orgmailto: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.commailto: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.commailto:doug.hellm...@dreamhost.com wrote: On Mon, Jan 6, 2014 at 2:56 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.commailto: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
Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy
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 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 Reply-To: OpenStack Dev openstack-dev@lists.openstack.org Date: Wednesday, January 8, 2014 at 10:41 AM To: OpenStack Dev 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 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 Reply-To: OpenStack Dev openstack-dev@lists.openstack.org Date: Tuesday, January 7, 2014 at 6:54 AM To: OpenStack Dev 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 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 wrote: On Mon, Jan 6, 2014 at 2:56 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi, In Solum project we will need
Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy
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
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 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 wrote: On Mon, Jan 6, 2014 at 2:56 PM, Georgy Okrokvertskhov 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 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 -- 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@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
Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy
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.commailto:doug.hellm...@dreamhost.com Reply-To: OpenStack Dev openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, January 7, 2014 at 6:54 AM To: OpenStack Dev openstack-dev@lists.openstack.orgmailto: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.commailto: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.commailto:doug.hellm...@dreamhost.com wrote: On Mon, Jan 6, 2014 at 2:56 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.commailto: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.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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.comhttp://www.mirantis.com/ Tel. +1 650 963 9828tel:%2B1%20650%20963%209828 Mob. +1 650 996 3284tel:%2B1%20650%20996%203284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev
[openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy
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? Thanks Georgy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy
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? Thanks Georgy On Mon, Jan 6, 2014 at 2:45 PM, Doug Hellmann doug.hellm...@dreamhost.comwrote: On Mon, Jan 6, 2014 at 2:56 PM, Georgy Okrokvertskhov 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 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 -- 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
