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
parent
bc2f3c07ed
commit
9e35b2081a
|
|
@ -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
|
||||
---------
|
||||
|
|
|
|||
|
|
@ -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|:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue