Copy security pages from deploy-guide
This PR is part of the ongoing work to migrate pages
from the deploy-guide to the charm-guide that are not
specific to a manual test cloud deployment.
The filename for the TLS page was renamed to tls.rst .
Some links necessarily needed to be changed in some
files.
Two trivial format corrections were made:
i) in keystone.rst
_keyston_tokens: => _keystone_tokens:
ii) in tls.rst
csr => CSR
Change-Id: I20e89f4daa21f853ebaec8d928a7d0dc479512d8
This commit is contained in:
Peter Matulis
parent
fbcd9fb0cf
commit
75c3a0a89c
|
|
@ -776,8 +776,8 @@ are working nova-compute and vault applications.
|
|||
|
||||
Finally, you will need to provide an SSL certificate. This can be done by
|
||||
having Vault use a self-signed certificate or by using a certificate chain.
|
||||
We'll do the former here for simplicity but see `Managing TLS certificates`_
|
||||
for how to use a chain.
|
||||
We'll do the former here for simplicity but see :doc:`security/tls` for how to
|
||||
use a chain.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
|
@ -865,7 +865,6 @@ Charms`_ project group.
|
|||
.. _Clustered Database Service Model: http://docs.openvswitch.org/en/latest/ref/ovsdb.7/#clustered-database-service-model
|
||||
.. _Raft algorithm: https://raft.github.io/
|
||||
.. _Ceph bucket type: https://docs.ceph.com/docs/master/rados/operations/crush-map/#types-and-buckets
|
||||
.. _Managing TLS certificates: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-certificate-management.html
|
||||
.. _Managing power events: https://docs.openstack.org/charm-guide/latest/howto/managing-power-events.html
|
||||
|
||||
.. BUGS
|
||||
|
|
|
|||
|
|
@ -95,3 +95,12 @@ Networking
|
|||
networking/hardware-offloading
|
||||
networking/load-balancing
|
||||
networking/interface-config
|
||||
|
||||
Security
|
||||
~~~~~~~~
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
security/keystone
|
||||
security/tls
|
||||
|
|
|
|||
|
|
@ -106,8 +106,7 @@ network space can be used for all Masakari bindings.
|
|||
|
||||
If the cloud is TLS-enabled via Vault then a relation is needed between the
|
||||
masakari and vault applications. Uncomment the relation in the overlay bundle
|
||||
to achieve this. See :doc:`cdg:app-certificate-management` in the Deploy Guide
|
||||
for background information.
|
||||
to achieve this. See the :doc:`security/tls` page for background information.
|
||||
|
||||
.. important::
|
||||
|
||||
|
|
|
|||
|
|
@ -157,8 +157,8 @@ Avoid expired Keystone tokens
|
|||
|
||||
Keystone token expiration times should be increased when dealing with oversized
|
||||
VMs as expired tokens will prevent the cloud database from being updated. This
|
||||
will lead to migration failure and a corrupted database entry. See `Keystone
|
||||
tokens`_ in the OpenStack Charms Deployment Guide.
|
||||
will lead to migration failure and a corrupted database entry (see
|
||||
:ref:`keystone_tokens`).
|
||||
|
||||
To set the token expiration time to three hours (from the default one hour):
|
||||
|
||||
|
|
@ -379,4 +379,3 @@ A failed migration will result in log messages being appended to the
|
|||
.. LINKS
|
||||
.. _nova-compute charm: https://jaas.ai/nova-compute
|
||||
.. _SSH keys and VM migration: https://opendev.org/openstack/charm-nova-compute/src/branch/master/README.md#ssh-keys-and-vm-migration
|
||||
.. _Keystone tokens: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/keystone.html#token-support
|
||||
|
|
|
|||
|
|
@ -0,0 +1,205 @@
|
|||
.. role:: raw-html(raw)
|
||||
:format: html
|
||||
|
||||
========
|
||||
Keystone
|
||||
========
|
||||
|
||||
Security compliance
|
||||
-------------------
|
||||
|
||||
The keystone charm's ``password-security-compliance`` configuration option sets
|
||||
the ``[security_compliance]`` section of Keystone's configuration file. The
|
||||
value of this option is a YAML dictionary that includes support for the
|
||||
following keys (value formats and units are also included).
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
change_password_upon_first_use: <boolean>
|
||||
disable_user_account_days_inactive: <int> (days)
|
||||
lockout_duration: <int> (seconds)
|
||||
lockout_failure_attempts: <int>
|
||||
minimum_password_age: <int> (days)
|
||||
password_expires_days: <int> (days)
|
||||
password_regex: <string>
|
||||
password_regex_description: <string>
|
||||
unique_last_password_count: <int>
|
||||
|
||||
.. important::
|
||||
|
||||
The upstream document `Security compliance and PCI-DSS`_ should be consulted
|
||||
before setting any of these options.
|
||||
|
||||
The configuration is typically contained within a file, say ``config.yaml``.
|
||||
For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
password-security-compliance:
|
||||
change_password_upon_first_use: True
|
||||
lockout_duration: 1800
|
||||
lockout_failure_attempts: 3
|
||||
...
|
||||
|
||||
It is applied in the usual way:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju config keystone --file config.yaml
|
||||
|
||||
The charm will protect service accounts (accounts requested by other units that
|
||||
are in the service domain) against being forced to change their password.
|
||||
Operators should also ensure that any other accounts are protected as per the
|
||||
above referenced note.
|
||||
|
||||
Operators should also ensure that any non-service accounts are protected as per
|
||||
the upstream document.
|
||||
|
||||
The charm will enter a blocked state if the value of charm option
|
||||
``password-security-compliance`` is not in valid YAML format and/or the
|
||||
individual service options do not conform to the proper value formats.
|
||||
|
||||
.. _keystone_tokens:
|
||||
|
||||
Token support
|
||||
-------------
|
||||
|
||||
Over time OpenStack has come to support two Keystone token formats: UUID and
|
||||
Fernet.
|
||||
|
||||
Fernet tokens were added to address the issue of size observed with PKI and
|
||||
PKIZ tokens in addition to continuing the Keystone behaviour of persisting
|
||||
tokens to a common database cluster (like UUID tokens). For more information
|
||||
see this `Fernet FAQ`_.
|
||||
|
||||
.. important::
|
||||
|
||||
Starting with OpenStack Rocky, only the Fernet format for authentication
|
||||
tokens is supported. This is documented as a `known upgrade issue`_.
|
||||
|
||||
Fernet keys
|
||||
-----------
|
||||
|
||||
Theory of operation
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Keystone generates Fernet keys, which in turn are used to generate/encrypt
|
||||
and decode/decrypt Fernet tokens.
|
||||
|
||||
There are three key types, and each is associated with a naming scheme that is
|
||||
applied to the directories in which they are found. Directory names are based
|
||||
on integers:
|
||||
|
||||
* primary key
|
||||
* integer: the highest one
|
||||
* generates tokens
|
||||
* number of keys: one
|
||||
|
||||
* staged key
|
||||
* integer: '0'
|
||||
* will become the next primary key
|
||||
* can decode tokens
|
||||
* number of keys: one
|
||||
|
||||
* secondary key
|
||||
* integer: any other number
|
||||
* was previously a primary key
|
||||
* can decode tokens
|
||||
* number of keys: one or more
|
||||
|
||||
Each key type must be present at all times. This means Keystone uses a minimum
|
||||
of three keys.
|
||||
|
||||
Key rotation
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Key rotation refers to the process by which two keys assume a different type,
|
||||
one key gets created, and typically one key gets removed:
|
||||
|
||||
#. staged :raw-html:`→` primary
|
||||
#. primary :raw-html:`→` secondary
|
||||
#. the staged is created
|
||||
#. a secondary is removed
|
||||
|
||||
A key will get removed if the total number of keys surpasses the specified
|
||||
maximum allowed (more on this later).
|
||||
|
||||
This process takes place on the master keystone unit and takes into account
|
||||
three aspects:
|
||||
|
||||
* rotation frequency
|
||||
* token expiration
|
||||
* maximum number of active keys
|
||||
|
||||
These are related according to this formula:
|
||||
|
||||
.. math::
|
||||
|
||||
max\_active\_keys = \frac{ token\_expiration }{ rotation\_frequency } + 2
|
||||
|
||||
In the keystone charm, token expiration and the maximum number of active keys
|
||||
are specified, respectively, with the ``token-expiration`` and the
|
||||
``fernet-max-active-keys`` configuration options.
|
||||
|
||||
For example, given that an administrator desires a token expiration of 1 hour
|
||||
(3600 seconds) and a rotation frequency of 15 minutes (900 seconds), the maximum
|
||||
number of active keys must be six:
|
||||
|
||||
.. math::
|
||||
|
||||
\begin{eqnarray}
|
||||
max\_active\_keys &=& \frac{ 3600 }{ 900 } + 2\\
|
||||
&=& 4+2\\
|
||||
&=& 6\\
|
||||
\end{eqnarray}
|
||||
|
||||
The above two options can then be set accordingly:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
token-expiration: 3600
|
||||
fernet-max-active-keys: 6
|
||||
|
||||
Rotation frequency
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
From the point of view of rotation frequency:
|
||||
|
||||
.. math::
|
||||
|
||||
rotation\_frequency = \frac{ token\_expiration }{ max\_active\_keys - 2 }
|
||||
|
||||
Since the denominator must lead to a positive real number for rotation
|
||||
frequency the value of ``fernet-max-active-keys`` must be at least three, and
|
||||
this constraint is enforced by the charm.
|
||||
|
||||
To increase rotation frequency either decrease ``fernet-max-active-keys`` or
|
||||
increase ``token-expiration``. To decrease rotation frequency, do the opposite.
|
||||
|
||||
The most notable effect of increasing rotation frequency is the reduction in
|
||||
key lifetime (secondary keys get removed more often).
|
||||
|
||||
Default values
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
These are the default values for these keystone charm options and the resulting
|
||||
default rotation frequency:
|
||||
|
||||
* ``token-expiration``: 3600 sec (1 hour)
|
||||
* ``fernet-max-active-keys``: 3
|
||||
* ``rotation frequency``: 3600 sec (1 hour)
|
||||
|
||||
Token validation breakage
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Token validation breakage is a situation in which a decoding key is no longer
|
||||
available to validate an unexpired token. This can be caused by a rotation
|
||||
frequency that has been set too high (a very short key lifetime) or by keys
|
||||
failing to synchronise (from the master keystone unit to the other units) prior
|
||||
to the succeeding rotation. Incremental changes to rotation frequency is
|
||||
therefore advised.
|
||||
|
||||
.. LINKS
|
||||
.. _Security compliance and PCI-DSS: https://docs.openstack.org/keystone/latest/admin/configuration.html#security-compliance-and-pci-dss
|
||||
.. _Fernet FAQ: https://docs.openstack.org/keystone/pike/admin/identity-fernet-token-faq.html
|
||||
.. _known upgrade issue: upgrade-issues.html#keystone-and-fernet-tokens-upgrading-from-queens-to-rocky
|
||||
|
|
@ -0,0 +1,335 @@
|
|||
=========================
|
||||
Managing TLS certificates
|
||||
=========================
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The encryption of API endpoints in an OpenStack cloud requires a method for the
|
||||
creation and distribution of TLS certificates, as well as the management of a
|
||||
certificate authority (CA). Charmed OpenStack supports two ways of doing this:
|
||||
|
||||
#. on a per-model basis (using the vault application)
|
||||
#. on a per-application basis (using charm configuration options)
|
||||
|
||||
.. note::
|
||||
|
||||
The recommended way to manage TLS in Charmed OpenStack is with Vault. It is
|
||||
a centrally managed encryption solution, it is designed for the task, and it
|
||||
integrates well with charms.
|
||||
|
||||
Certificate management with Vault
|
||||
---------------------------------
|
||||
|
||||
First ensure that Vault is deployed to the model containing the cloud and the
|
||||
required post-deployment steps have been completed. See the `vault`_ charm
|
||||
README for instructions.
|
||||
|
||||
The next step is to add a CA certificate to the model.
|
||||
|
||||
.. _add_ca_certificate:
|
||||
|
||||
Add a CA certificate
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For Vault to be able to issue certificates on your behalf you must equip it
|
||||
with a CA certificate. This is done in **one** of two ways:
|
||||
|
||||
#. a Vault-generated self-signed root CA certificate
|
||||
#. a third-party intermediate CA certificate
|
||||
|
||||
The Vault method is by far the simpler of the two.
|
||||
|
||||
Self-signed root CA certificate
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To have Vault generate a self-signed root CA certificate:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader generate-root-ca
|
||||
|
||||
You're done.
|
||||
|
||||
Third-party intermediate CA certificate
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The supported workflow for a third-party certificate involves three steps:
|
||||
|
||||
#. retrieve a Certificate Signing Request (CSR) for an intermediate CA from
|
||||
Vault
|
||||
#. transfer the CSR to an external CA to have a signed certificate created
|
||||
#. upload certificate information to Vault
|
||||
|
||||
Retrieve a CSR from Vault
|
||||
.........................
|
||||
|
||||
To retrieve a Vault-generated CSR run the ``get-csr`` action on the leader
|
||||
unit:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader get-csr
|
||||
|
||||
.. note::
|
||||
|
||||
The CSR may be rejected by the signing CA due to incorrect values for
|
||||
certain properties (e.g. common-name). It would be prudent therefore to
|
||||
inquire before generating the CSR. Use command :command:`juju actions
|
||||
--schema vault` for help on setting properties with action ``get-csr``.
|
||||
|
||||
This will produce output similar to:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
unit-vault-0:
|
||||
UnitId: vault/0
|
||||
id: "8"
|
||||
results:
|
||||
Stdout: |
|
||||
lxc
|
||||
lxc
|
||||
active
|
||||
lxc
|
||||
output: |-
|
||||
-----BEGIN CERTIFICATE REQUEST-----
|
||||
MIICijCCAXICAQAwRTFDMEEGA1UEAxM6VmF1bHQgSW50ZXJtZWRpYXRlIENlcnRp
|
||||
ZmljYXRlIEF1dGhvcml0eSAoY2hhcm0tcGtpLWxvY2FsKTCCASIwDQYJKoZIhvcN
|
||||
AQEBBQADggEPADCCAQoCggEBAJvof3Gut71YY9Ke3TlAYT+AoVUu8w0q2DKGh7dL
|
||||
5mUggcvThZuckbuj8IJZZ3pl5D114REcRRH9DIRxp4tH0TSmnb0PJLdjnuLyMQqy
|
||||
/IEipmSQWiILBF8c/QjYqEkvUoprADeJ+9L9KGc/axwuIoLWHqaXLnkSFzypgyz+
|
||||
9Qvxir4wSPvyygZVUDJvUoEekk/sMBidzpEaKuMF7U+aZAdlZvEPr39FilEwcUgQ
|
||||
EY2m3bDDe5maNcD6+la95ENuo0kuHF6wkjXuLGkzDV5xYBMtSO8sqymwRA1CPLyr
|
||||
WIA+ciDQ11Hy+1Q+YTurOoWzmr48QPlamCZEIz8BZeuf8vsCAwEAAaAAMA0GCSqG
|
||||
SIb3DQEBCwUAA4IBAQAoPhk5k5nXpFSYfbsOvm8Rc0hHUTfEHgB4xcQfzMrMTDMX
|
||||
fVmiJjGQhiM1q+eKNLLTDxuOGBBbyniQsveV6JZwpOlkOZ1YVdkw0EoaQndz6dEA
|
||||
JNjjelV2z1FxppKT3504uX/YkASTDnpb63aknE4W3C5aZSvyx/qw/WdUauCNnYoV
|
||||
NdFrzy0p2qm8kXwPsbjIwZTq/AqQ4t7UrNoXoONcxjAdq5UpuoBxgbRJJ7zr1RJp
|
||||
NUhVk/1qi9EQSGeigkuzGGPeRdBXvw4NXAXwnQfCiIBHgLEfkE3PVHNbXfVYqtjC
|
||||
3D2eeYPraKcSJIEts4DCJnbhj5FEzi1km9QgSZgA
|
||||
-----END CERTIFICATE REQUEST-----
|
||||
status: completed
|
||||
timing:
|
||||
completed: 2021-02-16 22:40:12 +0000 UTC
|
||||
enqueued: 2021-02-16 22:40:08 +0000 UTC
|
||||
started: 2021-02-16 22:40:09 +0000 UTC
|
||||
|
||||
Place the CSR data (minus any leading whitespace) in a file, say
|
||||
``~/csr_file``. In this example, the file's contents would be:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
-----BEGIN CERTIFICATE REQUEST-----
|
||||
MIICijCCAXICAQAwRTFDMEEGA1UEAxM6VmF1bHQgSW50ZXJtZWRpYXRlIENlcnRp
|
||||
ZmljYXRlIEF1dGhvcml0eSAoY2hhcm0tcGtpLWxvY2FsKTCCASIwDQYJKoZIhvcN
|
||||
AQEBBQADggEPADCCAQoCggEBAJvof3Gut71YY9Ke3TlAYT+AoVUu8w0q2DKGh7dL
|
||||
5mUggcvThZuckbuj8IJZZ3pl5D114REcRRH9DIRxp4tH0TSmnb0PJLdjnuLyMQqy
|
||||
/IEipmSQWiILBF8c/QjYqEkvUoprADeJ+9L9KGc/axwuIoLWHqaXLnkSFzypgyz+
|
||||
9Qvxir4wSPvyygZVUDJvUoEekk/sMBidzpEaKuMF7U+aZAdlZvEPr39FilEwcUgQ
|
||||
EY2m3bDDe5maNcD6+la95ENuo0kuHF6wkjXuLGkzDV5xYBMtSO8sqymwRA1CPLyr
|
||||
WIA+ciDQ11Hy+1Q+YTurOoWzmr48QPlamCZEIz8BZeuf8vsCAwEAAaAAMA0GCSqG
|
||||
SIb3DQEBCwUAA4IBAQAoPhk5k5nXpFSYfbsOvm8Rc0hHUTfEHgB4xcQfzMrMTDMX
|
||||
fVmiJjGQhiM1q+eKNLLTDxuOGBBbyniQsveV6JZwpOlkOZ1YVdkw0EoaQndz6dEA
|
||||
JNjjelV2z1FxppKT3504uX/YkASTDnpb63aknE4W3C5aZSvyx/qw/WdUauCNnYoV
|
||||
NdFrzy0p2qm8kXwPsbjIwZTq/AqQ4t7UrNoXoONcxjAdq5UpuoBxgbRJJ7zr1RJp
|
||||
NUhVk/1qi9EQSGeigkuzGGPeRdBXvw4NXAXwnQfCiIBHgLEfkE3PVHNbXfVYqtjC
|
||||
3D2eeYPraKcSJIEts4DCJnbhj5FEzi1km9QgSZgA
|
||||
-----END CERTIFICATE REQUEST-----
|
||||
|
||||
Have the CSR signed
|
||||
...................
|
||||
|
||||
The procedure for obtaining a signed certificate from an external CA is
|
||||
particular to the given CA, but it always entails sending the CSR to the CA
|
||||
(typically from its website) and waiting for a reply.
|
||||
|
||||
For informational purposes, an example CLI command is provided below. The exact
|
||||
command syntax is dependent upon the CA. Note the inclusion of the input file
|
||||
``~/csr_file``:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
openssl ca -config openssl.cnf -extensions v3_intermediate_ca -days 3650 \
|
||||
-notext -md sha256 -in ~/csr_file -out ~/vault-charm-int.pem -batch \
|
||||
-passin pass:secretpassword
|
||||
|
||||
.. note::
|
||||
|
||||
Depending on the services deployed on your cloud, the intermediate CA
|
||||
may need to issue both client and server certificates. Therefore, it is
|
||||
necessary to check the property of your external CA and grant the
|
||||
intermediate CA the proper level of authorization to issue both types
|
||||
of certificates.
|
||||
|
||||
The certificate is normally provided in PEM format, like the output file
|
||||
``~/vault-charm-int.pem`` in the above command. A root CA certificate should
|
||||
also be provided and placed in, say, file ``~/root-ca.pem``.
|
||||
|
||||
Upload the signed certificate and the root CA certificate to Vault
|
||||
..................................................................
|
||||
|
||||
To upload certificate information to Vault run the ``upload-signed-csr``
|
||||
action on the leader unit:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader upload-signed-csr \
|
||||
pem="$(cat ~/vault-charm-int.pem | base64)" \
|
||||
root-ca="$(cat ~/root-ca.pem | base64)" \
|
||||
allowed-domains='openstack.local'
|
||||
|
||||
The file that the ``pem`` parameter refers to must contain a PEM bundle
|
||||
consisting of:
|
||||
|
||||
#. the signed certificate
|
||||
#. any other intermediate CA certificates
|
||||
#. the root CA certificate
|
||||
|
||||
The file that the ``root-ca`` parameter refers to must contain a PEM bundle
|
||||
consisting of:
|
||||
|
||||
#. any other intermediate CA certificates
|
||||
#. the root CA certificate
|
||||
|
||||
.. important::
|
||||
|
||||
Omitting the (other) intermediate certificate information will result in the
|
||||
new certificate being rejected (due to an incomplete trust chain).
|
||||
|
||||
See the following resources:
|
||||
|
||||
* `RFC5280`_: for details concerning certificate paths and trust
|
||||
* `RFC7468`_: for details on the format of certificate PEM bundles
|
||||
|
||||
Issuing of certificates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Now that Vault is in possession of a CA certificate it will be able to issue
|
||||
certificates to clients (API services). Client requests are made via the
|
||||
``vault:certificates`` relation. For example:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju add-relation keystone:certificates vault:certificates
|
||||
juju add-relation nova-cloud-controller:certificates vault:certificates
|
||||
juju add-relation cinder:certificates vault:certificates
|
||||
juju add-relation neutron-api:certificates vault:certificates
|
||||
juju add-relation glance:certificates vault:certificates
|
||||
|
||||
A request will result in the transfer of certificates and keys from Vault. The
|
||||
corresponding API endpoint will also be updated in Keystone's service catalogue
|
||||
list to reflect that it is now using HTTPS. The service is now TLS-enabled.
|
||||
|
||||
A special client is mysql-innodb-cluster, the cloud database. It has a
|
||||
self-signed certificate but it is recommended to use the one signed by Vault's
|
||||
CA:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju add-relation mysql-innodb-cluster:certificates vault:certificates
|
||||
|
||||
.. important::
|
||||
|
||||
Once Keystone is TLS-enabled every application that talks to Keystone (i.e.
|
||||
there exists a relation between the two) **must** be in possession of the
|
||||
CA certificate. This is achieved as a side-effect when enabling TLS for that
|
||||
application.
|
||||
|
||||
Verification
|
||||
~~~~~~~~~~~~
|
||||
|
||||
To verify the CA certificate begin by sourcing the cloud init file and
|
||||
inspecting the certificate's location and the Keystone API endpoint. The latter
|
||||
should be using HTTPS:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
source novarc
|
||||
env | grep -e OS_AUTH_URL -e OS_CACERT
|
||||
|
||||
Sample output is:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
OS_CACERT=/home/ubuntu/snap/openstackclients/common/root-ca.crt
|
||||
OS_AUTH_URL=https://10.0.0.215:5000/v3
|
||||
|
||||
API services can now be queried by referring explicitly to the certificate. The
|
||||
below tests correspond to the clients mentioned in the previous section:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
# Keystone
|
||||
openstack --os-cacert $OS_CACERT catalog list
|
||||
# Nova
|
||||
openstack --os-cacert $OS_CACERT server list
|
||||
# Cinder
|
||||
openstack --os-cacert $OS_CACERT volume list
|
||||
# Neutron
|
||||
openstack --os-cacert $OS_CACERT network list
|
||||
# Glance
|
||||
openstack --os-cacert $OS_CACERT image list
|
||||
|
||||
Reissuing of certificates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
New certificates can be reissued to all TLS-enabled clients by means of the
|
||||
``reissue-certificates`` action. See cloud operation `Reissue TLS
|
||||
certificates across the cloud`_ in the Admin Guide for details.
|
||||
|
||||
Switching between different types of CA certificates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is possible to switch between a self-signed root CA certificate
|
||||
and a third-party intermediate CA certificate after deployment.
|
||||
|
||||
.. Important::
|
||||
|
||||
Switching certificates will cause a short period of downtime for services
|
||||
using Vault as the certificate manager. Notably, a TLS-enabled Keystone will
|
||||
temporarily move to the ``maintainance`` state to update its endpoints.
|
||||
|
||||
From self-signed root certificate to third-party intermediate certificate
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To switch from a self-signed root CA certificate to a third-party intermediate
|
||||
CA certificate, you need to first disable the PKI secrets
|
||||
backend:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader disable-pki
|
||||
|
||||
This step deletes the existing root certificate and invalidates any previous
|
||||
CSR requests.
|
||||
|
||||
Next, follow the steps described in the
|
||||
`Third-party intermediate CA certificate`_ section above to retrieve a CSR
|
||||
from the Vault and have it signed by the external CA.
|
||||
|
||||
|
||||
Finally, upload both the signed intermediate certificate and the external root
|
||||
CA certificate to Vault:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader upload-signed-csr \
|
||||
pem=“$(cat /path/to/vault-charm-int.pem | base64)" \
|
||||
root-ca="$(cat /path/to/root-ca.pem | base64)"
|
||||
|
||||
From third-party intermediate certificate to self-signed root certificate
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To switch from an external certificate to a self-signed one first disable the
|
||||
PKI secrets backend and then generate a root CA certificate:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
juju run-action --wait vault/leader disable-pki
|
||||
juju run-action --wait vault/leader generate-root-ca
|
||||
|
||||
.. LINKS
|
||||
.. _RFC5280: https://tools.ietf.org/html/rfc5280#section-3.2
|
||||
.. _RFC7468: https://tools.ietf.org/html/rfc7468#section-5
|
||||
.. _vault: https://opendev.org/openstack/charm-vault/src/branch/master/src/README.md
|
||||
.. _Reissue TLS certificates across the cloud: https://docs.openstack.org/charm-guide/latest/admin/ops-reissue-tls-certs.html
|
||||
|
|
@ -402,7 +402,7 @@ Please see the `OpenStack Charm Guide`_ for current information.
|
|||
.. _Swift Auth system: https://docs.openstack.org/swift/latest/overview_auth.html
|
||||
.. _Multi-region cluster: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/swift.html#multi-region-cluster
|
||||
.. _Toward Convergence of ML2+OVS+DVR and OVN: http://specs.openstack.org/openstack/neutron-specs/specs/ussuri/ml2ovs-ovn-convergence.html
|
||||
.. _Vault: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-certificate-management.html
|
||||
.. _vault charm: https://charmhub.io/vault
|
||||
|
||||
.. BUGS
|
||||
.. _LP #1728527: https://bugs.launchpad.net/masakari-monitors/+bug/1728527
|
||||
|
|
|
|||
|
|
@ -619,7 +619,6 @@ Please see the `OpenStack Charm Guide`_ for current information.
|
|||
.. _Swift Auth system: https://docs.openstack.org/swift/latest/overview_auth.html
|
||||
.. _Swift Global Cluster: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-swift-gc.html
|
||||
.. _Toward Convergence of ML2+OVS+DVR and OVN: http://specs.openstack.org/openstack/neutron-specs/specs/ussuri/ml2ovs-ovn-convergence.html
|
||||
.. _Vault deployment and configuration: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-certificate-management.html
|
||||
.. _Security compliance and PCI-DSS: https://docs.openstack.org/keystone/train/admin/configuration.html#security-compliance-and-pci-dss
|
||||
.. _Keystone charm README: https://github.com/openstack/charm-keystone/blob/master/README.md
|
||||
.. _Neutron FWaaS project has been deprecated: https://review.opendev.org/#/c/708675/
|
||||
|
|
|
|||
|
|
@ -408,8 +408,8 @@ vault
|
|||
If a series upgrade is attempted while Vault is sealed then manual intervention
|
||||
will be required (see bugs `LP #1886083`_ and `LP #1890106`_). The vault leader
|
||||
unit (which will be in error) will need to be unsealed and the hook error
|
||||
resolved. The `Vault section`_ in the `OpenStack Charms Deployment Guide`_ has
|
||||
detailed unsealing instructions and the hook error can be resolved with:
|
||||
resolved. The `vault charm`_ documentation includes unsealing instructions, and
|
||||
the hook error can be resolved with:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
|
@ -450,7 +450,7 @@ Deployment Guide`_ for more details.
|
|||
.. _Upgrading to stable Arista charm: https://github.com/openstack/charm-neutron-api-plugin-arista/blob/master/docs/upgrading-to-stable.md
|
||||
.. _gnocchi charm README: https://github.com/openstack/charm-gnocchi/blob/master/src/README.md
|
||||
.. _keystone-kerberos charm README: https://opendev.org/openstack/charm-keystone-kerberos/src/branch/master/src/README.md
|
||||
.. _Vault section: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-certificate-management.html
|
||||
.. _vault charm: https://charmhub.io/vault
|
||||
.. _TrilioVault Data Protection: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-trilio-vault.html
|
||||
|
||||
.. COMMITS
|
||||
|
|
|
|||
|
|
@ -195,9 +195,8 @@ The symptom is missing sym links to certificates for Subject Alternative Name
|
|||
Apache configuration may fail as it will point to a certificate for the VIP(s).
|
||||
|
||||
The workaround is to set the above settings to False and utilise the
|
||||
post-deployment actions for preparing vault as documented in the `Vault
|
||||
section`_ and the `Certificate Lifecycle Management`_ section of the `OpenStack
|
||||
Charms Deployment Guide`_.
|
||||
post-deployment actions for preparing vault as documented in the `vault
|
||||
charm`_.
|
||||
|
||||
TrilioVault Data Mover charm upgrade
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -281,8 +280,8 @@ vault
|
|||
If a series upgrade is attempted while Vault is sealed then manual intervention
|
||||
will be required (see bugs `LP #1886083`_ and `LP #1890106`_). The vault leader
|
||||
unit (which will be in error) will need to be unsealed and the hook error
|
||||
resolved. The `Vault section`_ in the `OpenStack Charms Deployment Guide`_ has
|
||||
detailed unsealing instructions and the hook error can be resolved with:
|
||||
resolved. The `vault charm`_ documentation includes unsealing instructions, and
|
||||
the hook error can be resolved with:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
|
@ -319,9 +318,8 @@ Deployment Guide`_ for more details.
|
|||
.. _OpenStack Charms Deployment Guide: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest
|
||||
.. _OpenStack Charm Guide: https://docs.openstack.org/charm-guide/latest/
|
||||
.. _OpenStack upgrades: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-upgrade-openstack.html
|
||||
.. _Vault section: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-certificate-management.html
|
||||
.. _Open vSwitch Integration Guide for Centralized Control: https://docs.openvswitch.org/en/latest/topics/integration/
|
||||
.. _Certificate Lifecycle Management: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-certificate-management.html
|
||||
.. _vault charm: https://charmhub.io/vault
|
||||
.. _Migration from Neutron ML2+OVS to ML2+OVN section of the OVN: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-ovn.html#migration-from-neutron-ml2-ovs-to-ml2-ovn
|
||||
.. _Octavia deprecation notes for Victoria: https://docs.openstack.org/releasenotes/octavia/victoria.html#deprecation-notes
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue