You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After moving the nova APIs policy as per the new guidlines
where system scoped token will be only allowed to access
system level APIs and will not be allowed any operation
on project level APIs. With that we do not need below
base rules (who have hardcoded 'system_scope:all' check_str):
- system_admin_api
- system_reader_api
- system_admin_or_owner
- system_or_project_reader
At this stage (phase-1 target), we allow below roles as targeted
in phase-1 [1]
1. ADMIN(this is System Administrator with scope_type 'system'
when scope enabled otherwise legacy admin)
2. PROJECT_ADMIN
3. PROJECT_MEMBER
4. PROJECT_READER
& below one specific to nova
5. PROJECT_READER_OR_ADMIN (to allow system admin and project reader
to list flavor extra specs)
This complete the phase-1 of RBAC community-wide goal[2] for nova.
Add release notes too.
[1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#how-operator
[2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#yoga-timeline-7th-mar-2022
Partial implement blueprint policy-defaults-refresh-2
Change-Id: I075005d13ff6bfe048bbb21d80d71bf1602e4c02
and `system scope specification <https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html>`_ to understand the scope concept.
43
43
44
-
In the Nova 21.0.0 (Ussuri) release, Nova policies implemented
44
+
In the Nova 25.0.0 (Yoga) release, Nova policies implemented
45
45
the scope concept and default roles provided by keystone (admin, member,
46
46
and reader). Using common roles from keystone reduces the likelihood of
47
47
similar, but different, roles implemented across projects or deployments
@@ -112,15 +112,15 @@ Policies with a ``scope_type`` of ``system and project`` means a user with a
112
112
resource. All the system and project level operation's policies have defaulted
113
113
to ``scope_type`` of ``['system', 'project']``.
114
114
115
-
For example, consider the ``POST /servers/{server_id}/action (os-migrateLive)``
115
+
For example, consider the ``GET /flavors/{flavor_id}/os-extra_specs/{flavor_extra_spec_key}``
116
116
API.
117
117
118
118
.. code::
119
119
120
-
# Live migrate a server to a new host without a reboot
121
-
# POST /servers/{server_id}/action (os-migrateLive)
120
+
# Show an extra spec for a flavor
121
+
# GET /flavors/{flavor_id}/os-extra_specs/{flavor_extra_spec_key}
0 commit comments