User with reader role can perform similar operation as other roles

Bug #2072639 reported by Hemant
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
New
Undecided
Unassigned

Bug Description

Openstack Release: Zed (openstack deployed using openstack-helm)
OS: Ubuntu 22.04.2 LTS (Jammy)

Reader role in openstack can perform all the operations similar to member role. It looks like it has similar permissions as member role.

I tried to assign reader role to one of the newly created user and assign it to some project where some other member role user was also a part of it. I created Instance using member role and tried to delete it using reader role user which I managed to delete it. This is not only for instances reader role can also modify other openstack resources as well such as networks, volumes...etc

Reader role should only have limited access just to monitor the resources. It should not modify them.

I have also tried to add [oslo_policy] enforce_new_defaults = True in nova.conf but it did not helped. Also I tried to add it to keystone.conf where I was not even able to perform any operation with it in horizon. For e.g if i would have click on launch instance horizon was logging me out. I also realize that I was getting "You are not authorized to perform this operation" Error. In this case I was logged in as an admin.

I have attached nova policy file for reference.

Is there any specific policy configuration needed or some changes in the code of nova and keystone ?

Revision history for this message
Hemant (hemantsonawane95) wrote :
description: updated
description: updated
description: updated
description: updated
Revision history for this message
Markus Hentsch (mhen) wrote :

The reader role you are referring to is part of the Consistent and Secure Default RBAC rework[^1] (or SRBAC for short) and the new default role model.

The adoption of SRBAC is individual to each OpenStack service (e.g. Nova, Cinder, etc.). Keystone only provides the foundation but cannot enforce policies on foreign services, such as Nova, itself. Hence, this is unlikely a bug in Keystone but either a bug in Nova or (most likely) a mismatch of your Nova version or policy configuration.

Good call attaching your policy file! It clearly shows rules from before SRBAC was introduced to Nova.
Note how "os_compute_api:servers:create: rule:admin_or_owner" and "admin_or_owner: is_admin:True or project_id:%(project_id)s" only look at project relationship but not at the role (except for admin).

This is different in today's implementation of Nova[^2] where the role is checked to be "member" additionally.

You can try the following things:

a) Enable enforce_new_defaults and delete your policy.yaml for Nova, so that Nova falls back to its in-code policy defaults.

b) Build a new policy.yaml file based on oslopolicy-sample-generator[^3]

c) Delete your policy.yaml and generate a new policy file using oslopolicy-policy-generator[^4] (note that oslopolicy-policy-generator will use the current Nova configuration so you will really have to delete your policy file beforehand so that it outputs the in-code fallbacks!)

Hope that helps!

---

[^1]: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html

[^2]: https://docs.openstack.org/nova/latest/configuration/policy.html

[^3]: https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-sample-generator.html

[^4]: https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-policy-generator.html

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.