openstack
/
charm-deployment-guide
Code Issues Proposed changes

Improve TLS explanation 

Better explain how applications get TLS-enabled,
the cloud database in particular.

Change-Id: I8cb74c7cc8ddde61f86544db8feedf25253a5496
This commit is contained in:
Peter Matulis 2021-03-16 17:34:50 -04:00
parent 9073c711d6
commit b7f5823f27
2 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
deploy-guide/source/app-certificate-management.rst
View File

@ -210,6 +210,14 @@ 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.

8
deploy-guide/source/install-openstack.rst
View File

@ -244,6 +244,14 @@ status` should look similar to this:
vault/0* active idle 3/lxd/0 10.0.0.178 8200/tcp Unit is ready (active: true, mlock: disabled)
vault-mysql-router/0* active idle 10.0.0.178 Unit is ready
Cloud applications are TLS-enabled via the ``vault:certificates`` relation.
Below we start with the cloud database. Although the latter has a self-signed
certificate, it is recommended to use the one signed by Vault's CA:
.. code-block:: none
juju add-relation mysql-innodb-cluster:certificates vault:certificates
.. _neutron_networking:
Neutron networking