Invalid aliases in nova.policy

Bug #1934478 reported by zhaoleilc
6
This bug affects 1 person
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=<username> --os-user-domain-name=<domain> --os-password=<password> --os-project-name=<project> --os-project-domain-name=<domain> server create --network <network_id> --flavor <flavor_id> --image <image_id> server_name
3. Add these default aliases to policy.yaml
"context_is_admin": "role:admin"
"admin_or_owner": "is_admin:True or project_id:%(project_id)s"
"admin_api": "is_admin:True"
"system_admin_api": "role:admin and system_scope:all"
"system_reader_api": "role:reader and system_scope:all"
"project_admin_api": "role:admin and project_id:%(project_id)s"
"project_member_api": "role:member and project_id:%(project_id)s"
"project_reader_api": "role:reader and project_id:%(project_id)s"
"system_admin_or_owner": "rule:system_admin_api or rule:project_member_api"
"system_or_project_reader": "rule:system_reader_api or rule:project_reader_api"
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

Tags: api
tags: added: api
Revision history for this message
Ghanshyam Mann (ghanshyammann) wrote :

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/e7a7fd51d12d045ff134d55a4a1749c1feee0386/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.

Changed in nova:
status: New → Invalid
zhaoleilc (zhaoleilc)
description: updated
zhaoleilc (zhaoleilc)
description: updated
Revision history for this message
zhaoleilc (zhaoleilc) wrote :

Thank you for your reply. I got it.

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

Other bug subscribers

Remote bug watches

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