Help overriding Nova policies (Ussuri)

Ghanshyam Mann gmann at ghanshyammann.com
Mon Dec 26 22:08:34 UTC 2022


 ---- On Thu, 15 Dec 2022 01:52:43 -0800  Jérôme BECOT  wrote --- 
 > Hello,
 > 
 > I should miss something, and I need some help. I've updated some rules 
 > that I placed in the /etc/nova/policy.yaml file. I use all defaults for 
 > the olso policies (ie scope is not enabled).
 > 
 > When I generate the fulle policy with oslopolicy-policy-generator, the 
 > rules are applied in the generated output. If I test the policy with 
 > oslopolicy-checker under the user's token, the results matches the 
 > permissions, but Nova API continue to refuse the operation
 > 
 > Policy check for os_compute_api:os-flavor-manage:create failed with 
 > credentials

Problem:
-----------
We have two problem here.

First is 'oslopolicy-policy-generator' tool and its usage. This has come up
many times when deployers use this tool with the expectation that generated
the file will work the same as the default way which is not the case. Generated
file by this tool makes you move to the new defaults (remove old defaults and
so does the old token might stop working).

Generating the policy.yaml by oslopolicy-policy-generator tool actually enable the new
defaults even if you have disabled them in the configuration file (via enforce_new_defaults=false).
This tool generates the policy.yaml file by merging the overridden rules and defaults rules
(if no overridden rule then it takes the default one). The newly generated policy.yaml
does not contain the old deprecated rules in logical OR to new defaults (they are added
in logical OR via policy-in-code when there is no policy.yaml). This means only new defaults
will be enforced and depending on the difference between old and new defaults your existing
user token might stop working as you are indirectly moving to the new defaults.

I think I should clarify it in tool help messages or documents so that it is used in the right way.

The second problem we have with the Nova new defaults in Ussuri-Xena is that rules new defaults
contain the special string "system_scope:all" due to this disabling the scope via enforce_scope=false
does not actually disable the scope checks. This is why you are getting errors. This has been
fixed in the yoga release when we redesigned the new RBAC for Openstack.

Recommendation on OpenStack policy:
----------------------------------------------
* Due to the problem where scope checks cannot be disabled (until you override the rule to remove the
"system_scope:all" from rule check_str), we do not recommend enabling the new defaults and use
defaults where old defaults are present and keep your deployment working. 

* Keep the overridden rules only in policy.yaml file and let oslo_policy to take the defaults from
what is there in the code. This way things will work fine.

 
Workaround for Nova policy for Ussuri-Xena:
-----------------------------------------------------
If you enable the new defaults which is the case when you generate the file by 'oslopolicy-policy-generator'
the tool then you can do:

Option 1: Comment out all the rules in the file except overridden rules.

Option 2: Override the below base rules to remove the problematic "system_scope:all" string:
    "system_admin_api": "'role:admin"
    "system_reader_api": "'role:reader"
Please let me know if option 2 works fine for you.


-gmann

 > 
 > I'm using the openstack cli to make the request (openstack flavor create)
 > 
 > Thanks for your help
 > 
 > J
 > 
 > 
 > 



More information about the openstack-discuss mailing list