de38f2767f
Training labs parser will allow us to automatically parse RST code
to BASH. This BASH code in turn will be invoked by install-guides for
validating the install guides. To provide the correct information to the
parser for generating BASH code, there are a few changes required to the
RST syntax.
Introduces the following changes to RST syntax:
- `.. end`
This tag provides information for the parser to stop extracting the
given block which could be code, file injection or configuration
file edit.
- `.. endonly`
This tag provides information for the parser with the correct
distro-switch logic for identifying distro-specific code.
For .. only:: tags, it is better to avoid nesting. If nesting
is not avoidable then it is preferable to add the .. endonly
tag to close the outer block immediately.
- Extra new lines in code-blocks
Some commands in the code-blocks provides the expected output of the
given command. This is not a BASH command which we want to run but
rather some visual niceness for the users. These new lines provides
the parser information to identify the end of the command. This
basic logic would be something similar to find '\r\n' which at least
for python means new empty line.
- `mysql>`
Introducing this operator for mysql commands. This could potentially
be changed to `pgsql>` or similar for other SQL type databases.
This allows the parser to identify mysql commands and then run
them in mysql instead of in 'sh' or 'bash'.
- `.. path`
Introducing this tag to provide the parser with the information with
the path of the configuration file. Using the description text for
the same is not reliable since the description text may not be
consistent.
This commit should ideally introduce all the syntax changes required for
the parser to convert the code-blocks in here to BASH code. These
changes should have no impact on the HTML output of the RST code.
Change-Id: I47830b1bc61c8b1a0f3350932d15aa3ce88fa672
77 lines
2.7 KiB
ReStructuredText
77 lines
2.7 KiB
ReStructuredText
Security
|
|
~~~~~~~~
|
|
|
|
OpenStack services support various security methods including password,
|
|
policy, and encryption. Additionally, supporting services including the
|
|
database server and message broker support at least password security.
|
|
|
|
To ease the installation process, this guide only covers password
|
|
security where applicable. You can create secure passwords manually,
|
|
generate them using a tool such as
|
|
`pwgen <http://sourceforge.net/projects/pwgen/>`__, or by running the
|
|
following command:
|
|
|
|
.. code-block:: console
|
|
|
|
$ openssl rand -hex 10
|
|
|
|
.. end
|
|
|
|
For OpenStack services, this guide uses ``SERVICE_PASS`` to reference
|
|
service account passwords and ``SERVICE_DBPASS`` to reference database
|
|
passwords.
|
|
|
|
The following table provides a list of services that require passwords
|
|
and their associated references in the guide:
|
|
|
|
.. list-table:: **Passwords**
|
|
:widths: 50 60
|
|
:header-rows: 1
|
|
|
|
* - Password name
|
|
- Description
|
|
* - Database password (no variable used)
|
|
- Root password for the database
|
|
* - ``ADMIN_PASS``
|
|
- Password of user ``admin``
|
|
* - ``CINDER_DBPASS``
|
|
- Database password for the Block Storage service
|
|
* - ``CINDER_PASS``
|
|
- Password of Block Storage service user ``cinder``
|
|
* - ``DASH_DBPASS``
|
|
- Database password for the dashboard
|
|
* - ``DEMO_PASS``
|
|
- Password of user ``demo``
|
|
* - ``GLANCE_DBPASS``
|
|
- Database password for Image service
|
|
* - ``GLANCE_PASS``
|
|
- Password of Image service user ``glance``
|
|
* - ``KEYSTONE_DBPASS``
|
|
- Database password of Identity service
|
|
* - ``NEUTRON_DBPASS``
|
|
- Database password for the Networking service
|
|
* - ``NEUTRON_PASS``
|
|
- Password of Networking service user ``neutron``
|
|
* - ``NOVA_DBPASS``
|
|
- Database password for Compute service
|
|
* - ``NOVA_PASS``
|
|
- Password of Compute service user ``nova``
|
|
* - ``RABBIT_PASS``
|
|
- Password of user guest of RabbitMQ
|
|
|
|
OpenStack and supporting services require administrative privileges
|
|
during installation and operation. In some cases, services perform
|
|
modifications to the host that can interfere with deployment automation
|
|
tools such as Ansible, Chef, and Puppet. For example, some OpenStack
|
|
services add a root wrapper to ``sudo`` that can interfere with security
|
|
policies. See the `OpenStack Administrator Guide <http://docs.openstack.org/
|
|
admin-guide/compute-root-wrap-reference.html>`__
|
|
for more information.
|
|
|
|
Also, the Networking service assumes default values for kernel network
|
|
parameters and modifies firewall rules. To avoid most issues during your
|
|
initial installation, we recommend using a stock deployment of a supported
|
|
distribution on your hosts. However, if you choose to automate deployment
|
|
of your hosts, review the configuration and policies applied to them before
|
|
proceeding further.
|