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>

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

@@ -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 
+            hardware status,metrics) for the purposes of monitoring Linux
-            resources (for example, interfaces) of end users' containerized 
+            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
+      -  ``configurator`` - is the same as admin, however it cannot add/remove
-         perform changes to the system, but can read/show/list any data.
+         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.
 

doc/source/security/kubernetes/keystone-account-roles-64098d1abdc1.rst

@@ -4,8 +4,8 @@
 Keystone Account Roles
 ======================
 
-In |prod|, 3 different keystone roles are supported: ``admin``, ``member``
+In |prod|, 4 different keystone roles are supported: ``admin``, ``reader``,
-and ``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
+The ``configurator`` role is the same as ``admin`` role, however it cannot add/remove
-in the future, allowing a user with ``member`` role to execute some actions that
+users/groups (Keystone commands), cannot add/remove system secrets (Barbican
-change the system configuration.
+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``.

doc/source/security/kubernetes/manage-local-ldap-39fe3a85a528.rst

@@ -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``
+    ``configurator``
-        Set the Keystone role of the user to be created as ``member``.
+        Set the Keystone role of the user to be created as ``configurator``. For
-        This role is for future use, currently it has the same permissions as
+        this user role permission, see
-        Keystone ``reader`` role.
+        :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``.