Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team
On 06/02/2015 06:16 PM, David Lyle wrote: > The Horizon project also uses the nova policy.json file to do role based > access control (RBAC) on the actions a user can perform. If the defaults > are hidden in the code, that makes those checks a lot more difficult to > perform. Horizon will then get to duplicate all the hard coded defaults > in our code base. Fully understanding UI is not everyone's primary > concern, I will just point out that it's a terrible user experience to > have 10 actions listed on an instance that will only fail when actually > attempted by making the API call. > > To accomplish this level of RBAC, Horizon has to maintain a sync'd copy > of the nova policy file. The move to centralized policy is something I > am very excited about. But this seems to be a move in the opposite > direction. > > I think simply documenting the default values in the policy.json file > would be a simpler and more straight-forward approach. I think the > defcore resolution is also a documentation issue. I think we should separate what you want to do: * Determine Policy User Can Do With how you are are currently doing it: * Reading the nova policy.json file Because I definitely think that determining the policy the user can do is definitely something we all want, but reading the policy.json file only works if Horizon and the API servers are on the same nodes. Otherwise you are copying a bunch of stuff around. It also requires (today) a ton of the url logic in Nova to be duplicated in to Horizon because our policy names are weird. Documentation isn't really good enough, we'd actually like to WARN the operator if they did a silly thing with their policy to get preventive about configuration mistakes and errors. For that, we need a baseline. How I'd imagine this going is the following: Default Policy in Code => Patch Policy in policy.json on the API server => Dynamic Policy from Keystone (things to the right override things to the left) We could provide a /policy API resource for users to GET a policy definition that's relevant to them (and something more global with admin credentials). I would imagine this would only provide Default + Patch, if you wanted Dynamic you'd ask Keystone for that (once it exists). That would be a better near term fetching point from Horizon instead of syncing a file. In the Dynamic Policy world that would be the origin source of truth for Keystone to get started, and it could dynamically modify after that point. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team
Hello Sean! +1 on defaults, resource-url style entries, hierarchy But, in the interest of staying "declarative", I am not comfortable with having default policies in code. I would rather have a default nova policy.json file in the nova code base and if no policy.json is supplied, have the nova code copy over this default to the /etc location, and log the same. Admin related access changes are easier to determine in the custom policy.json, but with the introduction of roles, which could act as aliases, Policy.json can easily be morphed to become more promiscuous or ultra stringent. Harder to determine and alert. Also thinking that in the context of dynamic policies and being able via API to introduce policy changes that take into consideration new roles Introduced, can see policy changes being saved in the database, changes being logged, but also for ease of use/review, nice to write out to a policy.json file, one per project. Thanks Malini -Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] Sent: Wednesday, June 03, 2015 2:34 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team On 2 June 2015 at 17:22, Sean Dague wrote: > Nova has a very large API, and during the last release cycle a lot of > work was done to move all the API checking properly into policy, and > not do admin context checks at the database level. The result is a > very large policy file - > https://github.com/openstack/nova/blob/master/etc/nova/policy.json In summary, we need to make it easier for the deployer configuring the policy to "to the right thing". The plan to remove the ability to turn off API "extensions", so we get the Nova API back to a single official (microversioned) API, will make it more important that its easy to "maintain" policy tweaks. > This provides a couple of challenges. One of which is in recent > defcore discussions some deployers have been arguing that the > existence of policy files means that anything you can do with > policy.json is valid and shouldn't impact trademark usage, because the > knobs were given. Nova specifically states this is not ok - > https://github.com/openstack/nova/blob/master/doc/source/devref/policy > _enforcement.rst#existed-nova-api-being-restricted > however, we'd like to go a step further here. > > What we'd really like is sane defaults for policy that come from code, > not from etc files. So that a Nova deploy with an empty policy.json is > completely valid, and does a reasonable thing. > > Policy.json would then be just a set of overrides for existing policy. > That would make it a lot more clear what was changed from the existing > policy. > > We'd also really like the policy system to be able to WARN when the > server starts if the policy was changed in some way that could > negatively impact compatibility of the system, i.e. if functions that > we felt were essential were turned off. Because the default policy is > in code, we could have a view of the old and new world and actually > warn the Operator that they did a weird thing. > > Lastly, we'd actually really like to redo our policy to look more like > resource urls instead of extension names, as this should be a lot more > sensible to the administrators, and hopefully make it easier to think > about policy. Which I think means an aliasing facility in oslo.policy > to allow a graceful transition for users. (This may exist, I don't know). +1 to all that. One more thing to help those maintaining a policy that has several levels of "admin" (frankly the most acceptable use of policy tweaks, and something we might want to encode into our defaults at some point if clear patterns emerge). I think we need more hierarchy in the policy. For example, if you want to disable all floating ip actions, it would be nice if that was a single policy change. Basically having all floating ip actions inherit from the top level policy (i.e. the actions default to the top level policy, and have overrides when required). As we add extra API actions, or extra more granular policy items, it should default in a way thats easy to understand across an upgrade. > I'm happy to write specs here, but mostly wanted to have the > discussion on the list first to ensure we're all generally good with this > direction. Thanks for the awesome summary here. I have added this to the list of post summit actions I am (still!) compiling, in the section where we need folks to step on an own stuff: https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items Thanks, John __
Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team
On 2 June 2015 at 17:22, Sean Dague wrote: > Nova has a very large API, and during the last release cycle a lot of > work was done to move all the API checking properly into policy, and not > do admin context checks at the database level. The result is a very > large policy file - > https://github.com/openstack/nova/blob/master/etc/nova/policy.json In summary, we need to make it easier for the deployer configuring the policy to "to the right thing". The plan to remove the ability to turn off API "extensions", so we get the Nova API back to a single official (microversioned) API, will make it more important that its easy to "maintain" policy tweaks. > This provides a couple of challenges. One of which is in recent defcore > discussions some deployers have been arguing that the existence of > policy files means that anything you can do with policy.json is valid > and shouldn't impact trademark usage, because the knobs were given. Nova > specifically states this is not ok - > https://github.com/openstack/nova/blob/master/doc/source/devref/policy_enforcement.rst#existed-nova-api-being-restricted > however, we'd like to go a step further here. > > What we'd really like is sane defaults for policy that come from code, > not from etc files. So that a Nova deploy with an empty policy.json is > completely valid, and does a reasonable thing. > > Policy.json would then be just a set of overrides for existing policy. > That would make it a lot more clear what was changed from the existing > policy. > > We'd also really like the policy system to be able to WARN when the > server starts if the policy was changed in some way that could > negatively impact compatibility of the system, i.e. if functions that we > felt were essential were turned off. Because the default policy is in > code, we could have a view of the old and new world and actually warn > the Operator that they did a weird thing. > > Lastly, we'd actually really like to redo our policy to look more like > resource urls instead of extension names, as this should be a lot more > sensible to the administrators, and hopefully make it easier to think > about policy. Which I think means an aliasing facility in oslo.policy to > allow a graceful transition for users. (This may exist, I don't know). +1 to all that. One more thing to help those maintaining a policy that has several levels of "admin" (frankly the most acceptable use of policy tweaks, and something we might want to encode into our defaults at some point if clear patterns emerge). I think we need more hierarchy in the policy. For example, if you want to disable all floating ip actions, it would be nice if that was a single policy change. Basically having all floating ip actions inherit from the top level policy (i.e. the actions default to the top level policy, and have overrides when required). As we add extra API actions, or extra more granular policy items, it should default in a way thats easy to understand across an upgrade. > I'm happy to write specs here, but mostly wanted to have the discussion > on the list first to ensure we're all generally good with this direction. Thanks for the awesome summary here. I have added this to the list of post summit actions I am (still!) compiling, in the section where we need folks to step on an own stuff: https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team
On 2 June 2015 at 23:48, Kevin L. Mitchell wrote: > On Tue, 2015-06-02 at 16:16 -0600, David Lyle wrote: >> The Horizon project also uses the nova policy.json file to do role >> based access control (RBAC) on the actions a user can perform. If the >> defaults are hidden in the code, that makes those checks a lot more >> difficult to perform. Horizon will then get to duplicate all the hard >> coded defaults in our code base. Yeah, thats totally nuts. Policy discovery is the fix to this tight coupling I guess. >> Fully understanding UI is not >> everyone's primary concern, I will just point out that it's a terrible >> user experience to have 10 actions listed on an instance that will >> only fail when actually attempted by making the API call. We are super worried about this, at least I am. Its a bad API user experience. However, we are still getting the plumbing sorted to let us fix that. And no one has stepped up to own writing up the proposed solutions (yet...?) > For the record, the discussion at the summit also touched on the > discoverability of the policy affecting a given user/API. I don't > believe we considered the ordering between that and the defaults feature > we suggested, but I believe we can code a defaults mechanism to > dynamically generate an output file in the interim (as is done for > configuration now), which may improve the situation from Horizon's > standpoint, until the discoverability piece is in place. We were planning on having all the default lines commented out, but we can sure skip that if it helps horizon until the discoverable policy is complete. There should be something that works out there. Honestly, it probably has to be more than policy, the capabilities of the system as its configured, are also an important input into this. It seems harsh to assume the deployer has to setup their policy to accuratly reflect what the system is capable of. I hope that gets unified, possibly via dynamic policy "defaults", or ideally something less evil. Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team
On Tue, 2015-06-02 at 16:16 -0600, David Lyle wrote: > The Horizon project also uses the nova policy.json file to do role > based access control (RBAC) on the actions a user can perform. If the > defaults are hidden in the code, that makes those checks a lot more > difficult to perform. Horizon will then get to duplicate all the hard > coded defaults in our code base. Fully understanding UI is not > everyone's primary concern, I will just point out that it's a terrible > user experience to have 10 actions listed on an instance that will > only fail when actually attempted by making the API call. For the record, the discussion at the summit also touched on the discoverability of the policy affecting a given user/API. I don't believe we considered the ordering between that and the defaults feature we suggested, but I believe we can code a defaults mechanism to dynamically generate an output file in the interim (as is done for configuration now), which may improve the situation from Horizon's standpoint, until the discoverability piece is in place. -- Kevin L. Mitchell Rackspace __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team
The Horizon project also uses the nova policy.json file to do role based access control (RBAC) on the actions a user can perform. If the defaults are hidden in the code, that makes those checks a lot more difficult to perform. Horizon will then get to duplicate all the hard coded defaults in our code base. Fully understanding UI is not everyone's primary concern, I will just point out that it's a terrible user experience to have 10 actions listed on an instance that will only fail when actually attempted by making the API call. To accomplish this level of RBAC, Horizon has to maintain a sync'd copy of the nova policy file. The move to centralized policy is something I am very excited about. But this seems to be a move in the opposite direction. I think simply documenting the default values in the policy.json file would be a simpler and more straight-forward approach. I think the defcore resolution is also a documentation issue. David On Tue, Jun 2, 2015 at 10:31 AM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 06/02/2015 06:22 PM, Sean Dague wrote: > > Nova has a very large API, and during the last release cycle a lot > > of work was done to move all the API checking properly into policy, > > and not do admin context checks at the database level. The result > > is a very large policy file - > > https://github.com/openstack/nova/blob/master/etc/nova/policy.json > > > > This provides a couple of challenges. One of which is in recent > > defcore discussions some deployers have been arguing that the > > existence of policy files means that anything you can do with > > policy.json is valid and shouldn't impact trademark usage, because > > the knobs were given. Nova specifically states this is not ok - > > https://github.com/openstack/nova/blob/master/doc/source/devref/policy > _enforcement.rst#existed-nova-api-being-restricted > > > > > however, we'd like to go a step further here. > > > > What we'd really like is sane defaults for policy that come from > > code, not from etc files. So that a Nova deploy with an empty > > policy.json is completely valid, and does a reasonable thing. > > > > Policy.json would then be just a set > > ofhttp://docs.openstack.org/developer/oslo.policy/api.html#rule-check > > overrides for existing policy. That would make it a lot more clear > > what was changed from the existing policy. > > > > We'd also really like the policy system to be able to WARN when > > the server starts if the policy was changed in some way that could > > negatively impact compatibility of the system, i.e. if functions > > that we felt were essential were turned off. Because the default > > policy is in code, we could have a view of the old and new world > > and actually warn the Operator that they did a weird thing. > > > > Lastly, we'd actually really like to redo our policy to look more > > like resource urls instead of extension names, as this should be a > > lot more sensible to the administrators, and hopefully make it > > easier to think about policy. Which I think means an aliasing > > facility in oslo.policy to allow a graceful transition for users. > > (This may exist, I don't know). > > If I understand your aliasing need correctly, you may want to use > RuleChecks: > http://docs.openstack.org/developer/oslo.policy/api.html#rule-check > > > > > I'm happy to write specs here, but mostly wanted to have the > > discussion on the list first to ensure we're all generally good > > with this direction. > > > > -Sean > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJVbdp7AAoJEC5aWaUY1u57/x0H/0G2aGlfNVyUdcflC19sner6 > FobWh/ASS/fBLq2SjDGduieu/voCdvK8XKi4rTncSvcwuKGVkgmJ/G3YiO22ZPyn > kPFWtQjiSadRdmP3WRmMYU4LeHw090Gxq32lBA7knpqon2f/MTHLPZUsnqdmX5R8 > J7zpGEj+nqe9RiWq4kJzwK8niwZTe4FP5+wvc3A+QYNbHNJB5feY5VnGMuUK/4O/ > svsmuNMyAz93GCZL36f+EJoXXQv7+tGtSuImANq505Ae6sXs+Bl7crZul9lkzHo7 > VB/UCbcxa208iw6tiWBh4qP1Y8vBljNjL8ifNbyXj6Y0z3gekEtoUcBQq3T0w5s= > =lBtm > -END PGP SIGNATURE- > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/2015 06:22 PM, Sean Dague wrote: > Nova has a very large API, and during the last release cycle a lot > of work was done to move all the API checking properly into policy, > and not do admin context checks at the database level. The result > is a very large policy file - > https://github.com/openstack/nova/blob/master/etc/nova/policy.json > > This provides a couple of challenges. One of which is in recent > defcore discussions some deployers have been arguing that the > existence of policy files means that anything you can do with > policy.json is valid and shouldn't impact trademark usage, because > the knobs were given. Nova specifically states this is not ok - > https://github.com/openstack/nova/blob/master/doc/source/devref/policy _enforcement.rst#existed-nova-api-being-restricted > > however, we'd like to go a step further here. > > What we'd really like is sane defaults for policy that come from > code, not from etc files. So that a Nova deploy with an empty > policy.json is completely valid, and does a reasonable thing. > > Policy.json would then be just a set > ofhttp://docs.openstack.org/developer/oslo.policy/api.html#rule-check > overrides for existing policy. That would make it a lot more clear > what was changed from the existing policy. > > We'd also really like the policy system to be able to WARN when > the server starts if the policy was changed in some way that could > negatively impact compatibility of the system, i.e. if functions > that we felt were essential were turned off. Because the default > policy is in code, we could have a view of the old and new world > and actually warn the Operator that they did a weird thing. > > Lastly, we'd actually really like to redo our policy to look more > like resource urls instead of extension names, as this should be a > lot more sensible to the administrators, and hopefully make it > easier to think about policy. Which I think means an aliasing > facility in oslo.policy to allow a graceful transition for users. > (This may exist, I don't know). If I understand your aliasing need correctly, you may want to use RuleChecks: http://docs.openstack.org/developer/oslo.policy/api.html#rule-check > > I'm happy to write specs here, but mostly wanted to have the > discussion on the list first to ensure we're all generally good > with this direction. > > -Sean > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVbdp7AAoJEC5aWaUY1u57/x0H/0G2aGlfNVyUdcflC19sner6 FobWh/ASS/fBLq2SjDGduieu/voCdvK8XKi4rTncSvcwuKGVkgmJ/G3YiO22ZPyn kPFWtQjiSadRdmP3WRmMYU4LeHw090Gxq32lBA7knpqon2f/MTHLPZUsnqdmX5R8 J7zpGEj+nqe9RiWq4kJzwK8niwZTe4FP5+wvc3A+QYNbHNJB5feY5VnGMuUK/4O/ svsmuNMyAz93GCZL36f+EJoXXQv7+tGtSuImANq505Ae6sXs+Bl7crZul9lkzHo7 VB/UCbcxa208iw6tiWBh4qP1Y8vBljNjL8ifNbyXj6Y0z3gekEtoUcBQq3T0w5s= =lBtm -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
