Update StarlingX OpenStack Local CLI documentation

This commit updates the StarlingX OpenStack Local CLI documentation
to reflect the latest structural changes to StarlingX OpenStack
application with regards to the way container-backed local CLIs are
configured.

Story: 2010774
Task: 48413

Change-Id: I146401b7517c32f298b3c85c238b8350f7cee9cb
Signed-off-by: Luan Nunes Utimura <LuanNunes.Utimura@windriver.com>
This commit is contained in:
Luan Nunes Utimura 2023-07-25 12:02:21 -03:00
parent bc2f3c07ed
commit 9e35b2081a
3 changed files with 148 additions and 14 deletions

View File

@ -4,6 +4,8 @@
Security
========
.. _index-security-84d0d8aa401b-kubernetes:
----------
Kubernetes
----------
@ -41,6 +43,8 @@ Contents:
kubernetes/index-security-kub-81153c1254c3
.. _index-security-84d0d8aa401b-openstack:
---------
OpenStack
---------

View File

@ -9,8 +9,7 @@ Overview
|prod-os| is a containerized application running on top of |prod-long|.
Many security features are not specific to |prod-os|, and are documented in
.. xbooklink :ref:`Cloud Platform Security <overview-of-starlingx-security>`.
|prod-long| :ref:`Kubernetes Security <index-security-84d0d8aa401b-kubernetes>`.
This section covers security features that are specific to |prod-os|:

View File

@ -6,30 +6,96 @@
Use Local CLIs
==============
|prod-os| administration and other tasks can be carried out from the command
line interface (|CLI|)
|prod-os| administration and other tasks can be carried out from the
command-line interface (|CLI|).
.. rubric:: |context|
.. warning::
For security reasons, only administrative users should have |SSH| privileges.
For security reasons, only administrative users should have |SSH|
privileges.
The Local |CLI| can be accessed via the local console on the active controller
or via SSH to the active controller. This procedure illustrates how to set the
context of |CLI| commands to openstack and access openstack admin privileges.
You can access |prod-os| via container-backed Local |CLIs| from the active
controller node's local console or by |SSH|-ing to the |OAM| Floating IP
Address.
.. rubric:: |proc|
This procedure shows how to obtain the credentials to access Local |CLIs|,
depending on your account type, and provides guidance on how to customize
|prod-os|-specific resources and switch between |prod| and |prod-os| |CLI|
contexts.
#. Login into the local console of the active controller or login via |SSH| to
the |OAM| Floating IP.
.. rubric:: |prereq|
#. Setup admin credentials for the containerized openstack application.
In order for you to perform this procedure, you will need an account that is
either:
* the **Sysadmin Local Linux Account**; or
* a **Local LDAP Linux User Account**.
The **Sysadmin Local Linux Account** is the account that, by default, has
access to the credentials of the Keystone user **admin** that comes pre-created
with |prod-os|.
A **Local LDAP Linux User Account**, on the other hand, is an account with SSH
privileges that is typically configured with only access to the credentials of
a Keystone user *who has the same username* as the |LDAP| account. To create
such a composite Local |LDAP| and Keystone user account, see
:ref:`Manage Composite Local LDAP Accounts at Scale <manage-local-ldap-39fe3a85a528>`.
.. important::
The Local |LDAP| Linux User Account *must* be a member of the |LDAP| group
**openstack** to have access to the |prod-os| configuration files. This
group is automatically created and made available after |prod-os| is
applied on the platform.
You can add an |LDAP| account to the |LDAP| group **openstack** by running:
.. code-block:: none
# source /etc/platform/openrc
# OS_AUTH_URL=http://keystone.openstack.svc.cluster.local/v3
sudo ldapaddusertogroup <USER> openstack
See :ref:`Local LDAP Linux User Accounts <local-ldap-linux-user-accounts>`
for more details.
If this is your first access to the system, you can use the **Sysadmin Local
Linux Account** for Local CLI access.
.. rubric:: |proc|
#. Log in to the active controller via console or |SSH| to the |OAM| Floating
IP Address.
* If accessing with **Sysadmin Local Linux Account**, use the username
**sysadmin** with your <sysadmin-password>.
* If accessing with a **Local LDAP Linux Account**, use the username
and password for that account.
#. Acquire the Keystone credentials for |prod-os|.
* If accessing with **Sysadmin Local Linux Account**:
.. code-block:: none
$ source /var/opt/openstack/admin-openrc
~(keystone_admin)$
* If accessing with a **Local LDAP Linux Account**:
.. code-block:: none
$ source /var/opt/openstack/local_openstackrc
Enter password for Keystone user `ldap-user`:
Created file `/home/ldap-user/ldap-user-openrc-openstack`.
~(keystone_ldap-user)$
The Local |LDAP| Linux User Account should always
:command:`source /var/opt/openstack/local_openstackrc` to load Keystone
credentials. This command prompts the user for the Keystone password,
stores it in the local file ``<USER>-openrc-openstack`` and loads it.
Subsequent calls of
:command:`source /var/opt/openstack/local_openstackrc` will just load
the created local openrc file.
.. rubric:: |result|
@ -61,4 +127,69 @@ For example:
| eeda4642-db83..| xenial-server-cloudimg-amd64-disk1.img | active |
+----------------+----------------------------------------+--------+
If you need to run a |CLI| command that references a local file, then that file
must be copied to or created in the shared directory between the host and the
clients container. On the host side, the directory is located at
``/var/opt/openstack``.
.. note::
You can use a different directory for this purpose after specifying an
alternate path in the Helm overrides and reapplying the application:
.. code-block:: none
~(keystone_admin)$ system helm-override-update <app_name> clients openstack \
--reuse-values --set workingDirectoryPath=/var/opt/another-directory
~(keystone_admin)$ system application-apply <app_name>
If you are logged in as **sysadmin**, you just have to move your file to
``/var/opt/openstack`` and reference it by its filename:
.. code-block:: none
~(keystone_admin)$ mv ubuntu.qcow2 /var/opt/openstack/ubuntu.qcow2
~(keystone_admin)$ openstack image create --public --disk-format qcow2 \
--container-format bare --file ubuntu.qcow2 ubuntu_image
Similarly, if you are logged in as an |LDAP| user, you just have to move your
file to ``/var/opt/openstack/<USER>`` and reference it by its filename:
.. code-block:: none
~(keystone_ldap-user)$ mv ubuntu.qcow2 /var/opt/openstack/ldap-user/ubuntu.qcow2
~(keystone_ldap-user)$ openstack image create --public --disk-format qcow2 \
--container-format bare --file ubuntu.qcow2 ubuntu_image
.. note::
The subdirectory ``/var/opt/openstack/<USER>`` is created automatically
after the first execution of a command by an |LDAP| user. If it does not
exist, you can create it by running:
.. code-block:: none
~(keystone_ldap-user)$ mkdir -p /var/opt/openstack/${USER}
.. note::
After running :command:`source /var/opt/openstack/admin-openrc`, all
OpenStack |CLIs| are aliased to the containerized OpenStack |CLIs|.
This means that, after sourcing ``admin-openrc`` or ``local_openstackrc``,
the :command:`openstack` command no longer references the Platform
OpenStack |CLI|. Instead, it references the OpenStack |CLI| of the
containerized OpenStack application.
You can verify this by running:
.. code-block:: none
~(keystone_admin)$ source /var/opt/openstack/admin-openrc
~(keystone_admin)$ type openstack
openstack is aliased to `/var/opt/openstack/clients-wrapper.sh openstack'
If you want to go back to using the OpenStack Platform |CLIs|, you can do
so by clearing the aliases:
.. code-block:: none
~(keystone_admin)$ source /var/opt/openstack/clear-aliases.sh