New default/static keystone (starlingx API/CLI/GUI) access-control roles for 'configurator' and 'operator'

Story: 2011348
Task: 52141

Added new keystone roles ``operator`` and ``configurator``

Change-Id: I757ea19cbd9a915b66d9bef573900b9333efb90f
Signed-off-by: Ngairangbam Mili <ngairangbam.mili@windriver.com>
This commit is contained in:
Ngairangbam Mili
2025-05-28 06:04:05 +00:00
parent f72a007868
commit d3b98f119a
3 changed files with 49 additions and 18 deletions

View File

@@ -107,12 +107,33 @@ User Account Types
Keystone user accounts for each of your system administrators, with only
the required privileges.
- There are two static keystone roles for |prod| services:
- There are four static keystone roles for |prod| services:
- 'admin' - can run all commands.
- ``admin`` - can run all commands.
- 'reader' - has read-only access to |prod| services. The reader cannot
perform changes to the system, but can read/show/list any data.
- ``configurator`` - is the same as admin, however it cannot add/remove
users/groups (Keystone commands), add/remove system secrets
(Barbican commands) nor add/remove trusted |CAs| (system
ca-certificate-install/uninstall commands).
- ``operator`` - has read-only access to everything, however it can execute
operational commands on hosts (example: lock/unlock, resets, power
off/on) and can execute operational commands on subclouds (example:
manage/unmanage, backup management).
- ``reader`` - has read-only access to everything.
For any user role other than ``admin``, access to Keystone, Barbican apis
is denied. However, the following commands are allowed where only that user
information is shown in the output:
- openstack project list
- openstack user show <user>
- openstack token issue
- openstack project show
- **LDAP User Accounts**

View File

@@ -4,8 +4,8 @@
Keystone Account Roles
======================
In |prod|, 3 different keystone roles are supported: ``admin``, ``member``
and ``reader``.
In |prod|, 4 different keystone roles are supported: ``admin``, ``reader``,
``configurator``, and ``operator``.
Users with an ``admin`` role in the ``admin`` project can execute any action in the system.
@@ -54,9 +54,14 @@ project verification, so a user in a project different from ``admin`` may execut
them. Examples: :command:`alarm-list`, :command:`alarm-show`, :command:`alarm-summary`,
:command:`event-list`, :command:`event-show` and :command:`event-suppress-list`.
Currently, the ``member`` role is equivalent to ``reader`` role, but this may change
in the future, allowing a user with ``member`` role to execute some actions that
change the system configuration.
The ``configurator`` role is the same as ``admin`` role, however it cannot add/remove
users/groups (Keystone commands), cannot add/remove system secrets (Barbican
commands) nor add/remove trusted |CAs| (system ca-certificate-install/uninstall
commands).
The ``operator`` role has read-only access to everything, however can execute operational
commands on hosts (example: lock/unlock, resets, power off/on) and can execute
operational commands on subclouds (example: manage/unmanage, backup management).
The following sections describe how to create users with specific keystone
roles in |prod|.

View File

@@ -140,10 +140,15 @@ Extra-vars parameter options:
Set the Keystone role of the user to be created as ``admin``.
This role has permissions to execute all |prod| CLI commands.
``member``
Set the Keystone role of the user to be created as ``member``.
This role is for future use, currently it has the same permissions as
Keystone ``reader`` role.
``configurator``
Set the Keystone role of the user to be created as ``configurator``. For
this user role permission, see
:ref:`introduction-to-user-management-6c0b13c6d325`.
``operator``
Set the Keystone role of the user to be created as ``operator``. For
this user role permission, see
:ref:`introduction-to-user-management-6c0b13c6d325`.
``reader``
Set the Keystone role of the user to be created as ``reader``.