diff --git a/doc/source/admin/ha.rst b/doc/source/admin/ha.rst index a4525663..f9d63283 100644 --- a/doc/source/admin/ha.rst +++ b/doc/source/admin/ha.rst @@ -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 diff --git a/doc/source/admin/index.rst b/doc/source/admin/index.rst index a92f4bbc..fd9582e6 100644 --- a/doc/source/admin/index.rst +++ b/doc/source/admin/index.rst @@ -95,3 +95,12 @@ Networking networking/hardware-offloading networking/load-balancing networking/interface-config + +Security +~~~~~~~~ + +.. toctree:: + :maxdepth: 1 + + security/keystone + security/tls diff --git a/doc/source/admin/instance-ha.rst b/doc/source/admin/instance-ha.rst index b551ab44..201665b9 100644 --- a/doc/source/admin/instance-ha.rst +++ b/doc/source/admin/instance-ha.rst @@ -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:: diff --git a/doc/source/admin/ops-live-migrate-vms.rst b/doc/source/admin/ops-live-migrate-vms.rst index 46eed02f..adb6c1ca 100644 --- a/doc/source/admin/ops-live-migrate-vms.rst +++ b/doc/source/admin/ops-live-migrate-vms.rst @@ -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 diff --git a/doc/source/admin/security/keystone.rst b/doc/source/admin/security/keystone.rst new file mode 100644 index 00000000..ad0f4c68 --- /dev/null +++ b/doc/source/admin/security/keystone.rst @@ -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: + disable_user_account_days_inactive: (days) + lockout_duration: (seconds) + lockout_failure_attempts: + minimum_password_age: (days) + password_expires_days: (days) + password_regex: + password_regex_description: + unique_last_password_count: + +.. 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 diff --git a/doc/source/admin/security/tls.rst b/doc/source/admin/security/tls.rst new file mode 100644 index 00000000..d3bd0ef2 --- /dev/null +++ b/doc/source/admin/security/tls.rst @@ -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 diff --git a/doc/source/release-notes/2002.rst b/doc/source/release-notes/2002.rst index ff023ec3..3aba374f 100644 --- a/doc/source/release-notes/2002.rst +++ b/doc/source/release-notes/2002.rst @@ -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 diff --git a/doc/source/release-notes/2005.rst b/doc/source/release-notes/2005.rst index 84f77223..0c1e5cc9 100644 --- a/doc/source/release-notes/2005.rst +++ b/doc/source/release-notes/2005.rst @@ -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/ diff --git a/doc/source/release-notes/2008.rst b/doc/source/release-notes/2008.rst index 6c604cb7..6ba31d2c 100644 --- a/doc/source/release-notes/2008.rst +++ b/doc/source/release-notes/2008.rst @@ -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 diff --git a/doc/source/release-notes/2010.rst b/doc/source/release-notes/2010.rst index e31b30b9..8fd487e8 100644 --- a/doc/source/release-notes/2010.rst +++ b/doc/source/release-notes/2010.rst @@ -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