From 932c0b1d73b06431f6aedab03e6f134524aaffaf Mon Sep 17 00:00:00 2001 From: Elisamara Aoki Goncalves Date: Mon, 24 Oct 2022 13:21:02 -0300 Subject: [PATCH] Create OpenLDAP certificate on bootstrap 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 Change-Id: I8001aef58fe6b206030462d15645cff7599d6d75 --- .../kubernetes/https-access-overview.rst | 4 + ...cates-to-use-cert-manager-c0b1727e4e5d.rst | 340 +++++++++--------- 2 files changed, 176 insertions(+), 168 deletions(-) diff --git a/doc/source/security/kubernetes/https-access-overview.rst b/doc/source/security/kubernetes/https-access-overview.rst index 7c7a9b2a7..878d56907 100644 --- a/doc/source/security/kubernetes/https-access-overview.rst +++ b/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. | +-----------------------------------------------------------+-----------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------+ diff --git a/doc/source/security/kubernetes/migrate-platform-certificates-to-use-cert-manager-c0b1727e4e5d.rst b/doc/source/security/kubernetes/migrate-platform-certificates-to-use-cert-manager-c0b1727e4e5d.rst index 7283bf618..96389dece 100644 --- a/doc/source/security/kubernetes/migrate-platform-certificates-to-use-cert-manager-c0b1727e4e5d.rst +++ b/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: - system_local_ca_key: - root_ca_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: - # Sudo password - ansible_become_pass: - - 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. 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: - ansible_become_pass: - hosts: - subcloud1: - subcloud2: - different_password_group2: - vars: - ansible_ssh_user: sysadmin - ansible_ssh_pass: - ansible_become_pass: - 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: + system_local_ca_key: + system_root_ca_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: + # Sudo password + ansible_become_pass: - .. 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.`` 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: + ansible_become_pass: + hosts: + subcloud1: + subcloud2: + different_password_group2: + vars: + ansible_ssh_user: sysadmin + ansible_ssh_pass: + ansible_become_pass: + 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.