starlingx/docs
Code Issues Proposed changes

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

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files

37
doc/source/security/kubernetes/introduction-to-user-management-6c0b13c6d325.rst
View File

@@ -65,8 +65,8 @@ User Types
|prod| physical hosts.
- |SSH| access provides access to local Linux services (for example,
hardware status,metrics) for the purposes of monitoring Linux
resources (for example, interfaces) of end users' containerized
hardware status,metrics) for the purposes of monitoring Linux
resources (for example, interfaces) of end users' containerized
applications hosted by |prod|.
User Account Types
@@ -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**
@@ -134,7 +155,7 @@ User Account Types
- For both, the Local |LDAP| scenario and the remote |LDAP| scenario, a
|LDAP| user (or members of a |LDAP| group), can be assigned linux
privileges via a group/role-binding to a local |prod| linux group,
specifically one or more of the following groups:
specifically one or more of the following groups:
- **sudo group** - provides sudo all capabilities.
@@ -147,7 +168,7 @@ User Account Types
- **root group** - provides read access to log files.
The Local |LDAP| scenario and the remote |LDAP| scenario, a |LDAP| user
can also be assigned to Kubernetes privileges through a Kubernetes
can also be assigned to Kubernetes privileges through a Kubernetes
ClusterRoleBinding/RoleBinding to either an existing Kubernetes
ClusterRole/Role or a new customer configured Kubernetes ClusterRole/Role.

17
doc/source/security/kubernetes/keystone-account-roles-64098d1abdc1.rst
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|.
@@ -96,4 +101,4 @@ role, use ``user_role=admin`` instead.
.. warning::
Users with ``reader`` role do not have ``sudo`` capabilities, use
``sudo_permission=false`` when the users role is ``user_role=reader``.
``sudo_permission=false`` when the users role is ``user_role=reader``.

13
doc/source/security/kubernetes/manage-local-ldap-39fe3a85a528.rst
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``.