starlingx/docs
Code Issues Proposed changes

Create OpenLDAP certificate on bootstrap

Browse Source 
Add OpenLDAP certificate to Platform Certificate docs
Fix greybar errors in output
Removed OpenLDAP item

Story: 2009834
Task: 46638

Signed-off-by: Elisamara Aoki Goncalves <elisamaraaoki.goncalves@windriver.com>
Change-Id: I8001aef58fe6b206030462d15645cff7599d6d75
This commit is contained in:
Elisamara Aoki Goncalves 2022-10-24 13:21:02 -03:00
parent cbe109ea6a
commit 932c0b1d73
2 changed files with 176 additions and 168 deletions

4
doc/source/security/kubernetes/https-access-overview.rst

@ -55,6 +55,10 @@ in the following sections.
+-----------------------------------------------------------+-----------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+
| |
+-----------------------------------------------------------+-----------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+
| OpenLDAP Server Certificate | Yes | auto-renewed by system |
+-----------------------------------------------------------+-----------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+
| |
+-----------------------------------------------------------+-----------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+
| OIDC Client and Dex Server Server Certificate | No | auto-renewed if configured with cert-manager; |
| | | NOT AUTO-RENEWED if configured with an externally generated certificate, CUSTOMER MUST renew via CLI. |
+-----------------------------------------------------------+-----------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+

340
doc/source/security/kubernetes/migrate-platform-certificates-to-use-cert-manager-c0b1727e4e5d.rst

@ -35,182 +35,186 @@ controllers/subclouds.
.. rubric:: |proc|
#. Create an inventory file using Ansible-Vault.
#. Create an inventory file using Ansible-Vault.
You must create an inventory file to specify the playbook parameters. Using
ansible-vault is highly recommended for enhanced security. Ansible vault
will ask for a password in this step, which is used for subsequent
ansible-vault access and ansible-playbook commands.
You must create an inventory file to specify the playbook parameters. Using
ansible-vault is highly recommended for enhanced security. Ansible vault
will ask for a password in this step, which is used for subsequent
ansible-vault access and ansible-playbook commands.
For example:
For example:
.. code-block:: none
.. code-block:: none
~(keystone_admin)]$ ansible-vault create migration-inventory.yml
~(keystone_admin)]$ ansible-vault create migration-inventory.yml
This will open up an editor in which you need to manually add or paste
your inventory parameters, as specified in the example below.
This will open up an editor in which you need to manually add or paste
your inventory parameters, as specified in the example below.
An example ``migration-inventory.yaml`` file is shown below:
An example ``migration-inventory.yaml`` file is shown below:
.. code-block:: none
.. code-block:: none
all:
vars:
system_local_ca_cert: <base64_cert>
system_local_ca_key: <base64_key>
root_ca_cert: <base64_cert>
children:
target_group:
vars:
dns_domain: xyz.com
duration: 2160h # 90d
renewBefore: 360h # 15d
subject_C: Canada
subject_ST: Ontario
subject_L: Ottawa
subject_O: myorganization
subject_OU: engineering
subject_CN: myorganization.com
subject_prefix: starlingx2`
# SSH password to connect to all subclouds
ansible_ssh_user: sysadmin
ansible_ssh_pass: <sysadmin-passwd>
# Sudo password
ansible_become_pass: <sysadmin-passwd>
The inventory parameters have the following meanings:
``system_local_ca_cert`` and ``system_local_ca_key``
You may choose to generate a certificate & key on the platform
(self-signed, internal Root |CA|) or use an external Root
|CA| that would make this an Intermediate |CA|.
``root_ca_cert``
The Root |CA| that signed ``system_local_ca_cert``. If
``system_local_ca_cert`` is a self-signed, internal Root |CA|
certificate, duplicate the value of ``system_local_ca_cert``
in this field.
``ca_duration``
|ICA| duration validation parameter. This will be used against
``system_local_ca_cert`` and ``root_ca_cert`` to ensure that they have
sufficient duration remaining. It defaults to 3 years, as this is
typical for |CA| certificates and this certificate must be renewed
manually. Only override if necessary.
``dns_domain``
The DNS domain that will be used to build the full dns name for
the |SANs| List of the Platform Certificates. E.g.
starlingx-restapi-gui.<dns_domain> would appear in the |SANs| list of
the REST API & Web Server certificate. in the server certificates.
``duration``
The duration of certificate validity to use in all Platform
Certificates, in hours. The Platform Server Certificates will be
auto-renewed by Cert-Manager.
``renewBefore``
The number of hours before certificate expiry that the Platform
Certificate should be auto-renewed by Cert-Manager.
``subject_*`` fields
Subject related fields that will be added to all platform certificates:
* ``subject_C``: country
* ``subject_ST``: State or Province
* ``subject_L``: Location
* ``subject_O``: Organization
* ``subject_OU``: Organization Unit
* ``subject_CN``: Common Name
* ``subject_prefix``: An optional field to add a prefix to further
identify the certificate, such as 'starlingx' for instance
``ansible_ssh_user``
The username to use to connect to the target system using ``ssh``.
``ansible_ssh_pass``
The password to use to connect to the target system using ``ssh``.
``ansible_become_pass``
The target system's sudo password.
If a separate set of overrides are required for a group of hosts,
``children`` groups can be added under ``target_group``.
The following example illustrates using one set of ssh/sudo passwords for
subcloud1 and subcloud2 and another set of ssh/sudo passwords for
subcloud3.
.. code-block:: none
all:
vars:
...
children:
target_group:
vars:
...
children:
different_password_group:
vars:
ansible_ssh_user: sysadmin
ansible_ssh_pass: <sysadmin-passwd>
ansible_become_pass: <sysadmin-passwd>
hosts:
subcloud1:
subcloud2:
different_password_group2:
vars:
ansible_ssh_user: sysadmin
ansible_ssh_pass: <different-sysadmin-passwd>
ansible_become_pass: <different-sysadmin-passwd>
hosts:
subcloud3:
#. Run the playbook.
Execute the Ansible playbook to start the migration process. You will be
prompted for the vault password created in the previous step.
For example:
.. code-block:: none
~(keystone_admin)]$ ansible-playbook /usr/share/ansible/stx-ansible/playbooks/migrate_platform_certificates_to_certmanager.yml -i migration-inventory.yml --extra-vars "target_list=subcloud1 mode=update ignore_alarms=yes" --ask-vault-pass
The behavior of the migration can be customized using the following
``--extra-vars`` parameter options:
``mode``
* ``update``: Creates or updates platform certificates. Also supports
ongoing updates, which is useful for operations such as such as
replacing the |ICA| or changing other parameters.
* ``check``: Gathers certificates from all subclouds and prints them on
the system controller
``target_list``
* ``subcloud1``, ``subcloud2``: A comma separated list of hosts the
playbook will target.
* ``localhost``: Will target the localhost (standalone systems or system
controller)
* ``all_online_subclouds``: Will query ``dcmanager subcloud list`` and
retrieve a list of online subclouds to target.
``ignore_alarms``
``yes``/``no``: When not specified defaults to no.
all:
vars:
system_local_ca_cert: <base64_cert>
system_local_ca_key: <base64_key>
system_root_ca_cert: <base64_cert>
children:
target_group:
vars:
system_platform_certificate:
dns_domain: xyz.com
duration: 2160h # 90d
renewBefore: 360h # 15d
subject_C: Canada
subject_ST: Ontario
subject_L: Ottawa
subject_O: myorganization
subject_OU: engineering
subject_CN: myorganization.com
subject_prefix: starlingx2`
# SSH password to connect to all subclouds
ansible_ssh_user: sysadmin
ansible_ssh_pass: <sysadmin-passwd>
# Sudo password
ansible_become_pass: <sysadmin-passwd>
.. note::
The inventory parameters have the following meanings:
The ``ignore_alarms`` extra-var should be avoided as much as possible.
Only use it after a careful analysis of the alarm in question and for
specific hosts.
``system_local_ca_cert`` and ``system_local_ca_key``
You may choose to generate a certificate & key on the platform
(self-signed, internal Root |CA|) or use an external Root
|CA| that would make this an Intermediate |CA|.
``system_root_ca_cert``
The Root |CA| that signed ``system_local_ca_cert``. If
``system_local_ca_cert`` is a self-signed, internal Root |CA|
certificate, duplicate the value of ``system_local_ca_cert`` in this
field.
``ca_duration``
|CA| duration validation parameter. This will be used against
``system_local_ca_cert`` and ``system_root_ca_cert`` to ensure that
they have sufficient duration remaining. It defaults to 3 years, as
this is typical for |CA| certificates and this certificate must be
renewed manually. Only override if necessary.
``system_platform_certificate.dns_domain``
The |DNS| domain that will be used to build the full dns name for the
|SANs| List of the Platform Certificates. E.g.
``starlingx-restapi-gui.<dns_domain>`` would appear in the |SANs| list
of the REST API & Web Server certificate. in the server certificates.
``system_platform_certificate.duration``
The duration of certificate validity to use in all Platform
Certificates, in hours. The Platform Server Certificates will be
auto-renewed by Cert-Manager.
``system_platform_certificate.renewBefore``
The number of hours before certificate expiry that the Platform
Certificate should be auto-renewed by Cert-Manager.
``system_platform_certificate.subject_*fields``
Subject related fields that will be added to all platform certificates:
- ``system_platform_certificate.subject_C``: country
- ``system_platform_certificate.subject_ST``: State or Province
- ``system_platform_certificate.subject_L``: Location
- ``system_platform_certificate.subject_O``: Organization
- ``system_platform_certificate.subject_OU``: Organization Unit
- ``system_platform_certificate.subject_CN``: Common Name
- ``system_platform_certificate.subject_prefix``: An optional field
to add a prefix to further identify the certificate, such as |prod|
for instance
``ansible_ssh_user``
The username to use to connect to the target system using ``ssh``.
``ansible_ssh_pass``
The password to use to connect to the target system using ``ssh``.
``ansible_become_pass``
The target system's sudo password.
If a separate set of overrides are required for a group of hosts,
``children`` groups can be added under ``target_group``.
The following example illustrates using one set of ssh/sudo passwords for
subcloud1 and subcloud2 and another set of ssh/sudo passwords for
subcloud3.
.. code-block:: none
all:
vars:
...
children:
target_group:
vars:
...
children:
different_password_group:
vars:
ansible_ssh_user: sysadmin
ansible_ssh_pass: <sysadmin-passwd>
ansible_become_pass: <sysadmin-passwd>
hosts:
subcloud1:
subcloud2:
different_password_group2:
vars:
ansible_ssh_user: sysadmin
ansible_ssh_pass: <different-sysadmin-passwd>
ansible_become_pass: <different-sysadmin-passwd>
hosts:
subcloud3:
#. Run the playbook.
Execute the Ansible playbook to start the migration process. You will be
prompted for the vault password created in the previous step.
For example:
.. code-block:: none
~(keystone_admin)]$ ansible-playbook /usr/share/ansible/stx-ansible/playbooks/migrate_platform_certificates_to_certmanager.yml -i migration-inventory.yml --extra-vars "target_list=subcloud1 mode=update ignore_alarms=yes" --ask-vault-pass
The behavior of the migration can be customized using the following
``--extra-vars`` parameter options:
``mode``
* ``update``: Creates or updates platform certificates. Also supports
ongoing updates, which is useful for operations such as such as
replacing the |ICA| or changing other parameters.
* ``check``: Gathers certificates from all subclouds and prints them on
the system controller
``target_list``
* ``subcloud1``, ``subcloud2``: A comma separated list of hosts the
playbook will target.
* ``localhost``: Will target the localhost (standalone systems or
system controller)
* ``all_online_subclouds``: Will query ``dcmanager subcloud list`` and
retrieve a list of online subclouds to target.
``ignore_alarms``
``yes``/``no``: When not specified defaults to no.
.. note::
The ``ignore_alarms`` extra-var should be avoided as much as possible.
Only use it after a careful analysis of the alarm in question and for
specific hosts.