Invalid aliases in nova.policy
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Description
===========
As of the Rocky release, keystone provides three roles called admin,
member, and reader by default. Nova has incorporated those available
roles into default policies in Victora version of OpenStack. Servers
, howver, can still be created by user who has only reader role in
Victoria version. The ambiguous thing is servers cannot be created
when I write the default aliases in the policy.yaml of nova.
Steps to reproduce
==================
1. Assign the reader role to the user, for example:
openstack role add --user alice --project acme reader
2. Create a server in acme project with user alice
openstack --os-username=
3. Add these default aliases to policy.yaml
"context_is_admin": "role:admin"
"admin_or_owner": "is_admin:True or project_
"admin_api": "is_admin:True"
"system_admin_api": "role:admin and system_scope:all"
"system_
"project_
"project_
"project_
"system_
"system_
4. repeat the third step
Expected result
===============
both the second and fourth step cannot create servers
Actual result
=============
the second step can create servers successfully
Yes, that is expected behaviour actually. Expected I mean until we remove the legacy policy rules where the reader is nothing but the owner.
We have not removed the legacy policy support yet and they are still present as deprecated rule
- https:/ /github. com/openstack/ nova/blob/ e7a7fd51d12d045 ff134d55a4a1749 c1feee0386/ nova/policies/ base.py# L127
This means, the old tokens still be able to pass the policy check and create the server. This is with the default policy in code which is your 2nd step.
Project reader in legacy policy is nothing but an owner of the project because in legacy policy there is no differentiation between the reader or member role in Nova. so any role in the project is the owner of the resource and that project so they can create a server. This is how we kept this policy migration as backward compatible.
Onew you override these policies as you did in step 3 then it removes the legacy policy support and that is why the reader will not be able to create a server.
Once we remove the legacy policy support, then new reader role will not be able to create server on new RBAC.
I hope I clarified the use case. If not please feel free to reopen it, until now I am marking as invalid because that is behaving as expected.