Keystone Account Roles

In StarlingX, 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.

Users with a reader role in the admin project have read-only access. They cannot perform any changes in the system but can read any configuration. In the CLI, commands with prefix or suffix, such as, list, query, show and summary get the configuration from the system, and are allowed for this type of user, all other commands are denied. Some examples of CLI commands executed by a user with reader role are shown below.

~(keystone_admin)]$ system host-list

+-----+--------------+-------------+----------------+-------------+--------------+
| id  | hostname     | personality | administrative | operational | availability |
+-----+--------------+-------------+----------------+-------------+--------------+
| 1   | controller-0 | controller  | unlocked       | enabled     | degraded     |
+-----+--------------+-------------+----------------+-------------+--------------+

~(keystone_admin)]$ system host-lock controller-0

Error: Forbidden

~(keystone_admin)]$ fm alarm-summary

+-----------------+--------------+--------------+----------+
| Critical Alarms | Major Alarms | Minor Alarms | Warnings |
+-----------------+--------------+--------------+----------+
| 1               | 13           | 0            | 0        |
+-----------------+--------------+--------------+----------+

~(keystone_admin)]$ fm event-suppress --alarm_id 100.103

Error: Forbidden.

Exception: all fm read-only commands require reader role but there is no project verification, so a user in a project different from admin may execute them. Examples: alarm-list, alarm-show, alarm-summary, event-list, event-show and event-suppress-list.

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 StarlingX.

Creation of user with specific role for Horizon only

Use the following commands to add a new user named readeruser with password “Passw0rd*” and role reader:

~(keystone_admin)]$ openstack user create readeruser --project admin --password Passw0rd*

~(keystone_admin)]$ openstack role add --project admin --user readeruser reader

To create a user with admin role instead of reader role, change reader to admin using the openstack role add command.

When this user is added in the central cloud, it is propagated to the managed subclouds. To check if this new user is already present in a host, use the openstack user list command.

Creation of user with specific role for Horizon and CLI

Follow the instructions in Manage Composite Local LDAP Accounts at Scale using the parameter user_role=reader in extra-vars of manage_local_ldap_account.yml playbook to create a user with reader role. To create a user with admin 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.