Updating cp-console hostname and TLS secret

Prerequisites

Keep your new hostname and certificates ready.

• Create the custom hostname. If you modify the default Red Hat® OpenShift® Container Platform domain, ensure that the new hostname can resolve to the Red Hat® OpenShift® Container Platform router from inside and outside the Red Hat® OpenShift® Container Platform cluster.

• Optional: If you are updating the TLS secret, provide new certificates in an unencrypted PEM format. Place the certificates in the installer_scripts directory. For more information, see Download and extract the installer scripts for your CASE bundle.

  Note: This step is applicable only if you need to update the certificates. If the certificates change or expire, you must provide new certificates and run the script again to create a secret by using the new certificates.

  • ca.crt: Contains the intermediate CA signer certificates and the CA root signer certificate. The file must start with the intermediate CA certificates in order that to lead the root CA.

  • tls.crt: Contains only the route server certificate.

    Note: The route server certificate passes the TLS verification for the route hostname.

  • tls.key: Contains the private key of the route server certificate.

  See the following example of PEM encoding that uses header and footer lines for each certificate and private key.

  -----BEGIN CERTIFICATE-----
  (encoded set of characters)
  -----END CERTIFICATE-----
  
  -----BEGIN PRIVATE KEY-----
  (encoded set of characters)
  -----END PRIVATE KEY-----
  

Procedure

Complete the following steps to change the cp-console hostname and certificates of the cp-console route.

1. Create a cs-onprem-tenant-config.yaml file with the following configmap definition. In the data section, provide your custom hostname. If you are providing new certificates to update the TLS secret, do not change the name of the custom_host_certificate_secret secret in the configmap.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cs-onprem-tenant-config
     namespace: <your-foundational-services-namespace>
   labels:
     cs_onprem_tenant_config: "true"
   data:
     ##comment out or remove this setting if not changing the hostname
     custom_hostname: <your-custom-hostname>
     ##comment out or remove this setting if not changing the certificates
     custom_host_certificate_secret: custom-tls-secret
   

   The following is the sample custom hostname:

   cp-testcustomhn.apps.o1-849902.cp.fyre.ibm.com
   

   Note: You need to update the custom_hostname: parameter with the URL that includes the domain name and new custom hostname without https:// protocol.

2. Create the cs-onprem-tenant-config configmap.

   oc apply -f cs-onprem-tenant-config.yaml
   

3. If your cluster topology has a separate namespace for all operators, identify that namespace and set it as the default namespace. You need to update the $csNamespace and $map_to_common_service_namespace in the script.

   1. Get the namespace where you deployed the foundational services.

      oc get csv -A | grep common-service-operator
      

      The following is the sample output:

      cp4itest                                           ibm-common-service-operator.v4.11.0            IBM Cloud Pak foundational services    4.11.0            ibm-common-service-operator.v4.10.0            Succeeded
      
      

      cp4itest is the namespace where foundational services is deployed and v4.11.0 is the CASE version

   2. Set the project with the default foundational services namespace.

      oc project <your-foundational-services-namespace>
      

      The following is the sample command:

      oc project cp4itest
      

4. Download and extract the installer scripts for your CASE bundle. To find your CASE version, see IBM: Product CASE to Application Version and search for the installed foundational services version to find the related CASE version.

   export CASE_VERSION=<your foundational service operator version>   
   
   wget https://github.com/IBM/cloud-pak/raw/master/repo/case/ibm-cp-common-services/${CASE_VERSION}/ibm-cp-common-services-${CASE_VERSION}.tgz
   
   tar -xvzf ibm-cp-common-services-$CASE_VERSION.tgz
   
   cd ibm-cp-common-services/inventory/ibmCommonServiceOperatorSetup/installer_scripts
   

   Replace CASE_VERSION with the foundational services version. To get the operator version, run the following command:

   oc get csv | grep "<your-foundational-services-namespace>"
   

5. Set the following environmental variables in the cs-onprem-tenant-config.sh script. To update the script, you can use the text editor or run one of the following commands in a system editor:

   vi cs-onprem-tenant-config.sh
   

   sudo nano cs-onprem-tenant-config.sh
   

   • $csNamespace - Set the operator namespace of the foundational services. The operator namespace is the control namespace where foundational services is deployed.
   • $map_to_common_service_namespace - Set the operand namespace of the foundational services where platform-auth-service-xxx pod is running.

   Note: If the operators and operands are in the same namespace, set $map_to_common_service_namespace and $csNamespace with <your-foundational-services-namespace>.

6. If you are providing new certificates for TLS secret, place the tls.key, tls.crt, and ca.crt files in the installer_scripts directory. Run the script to create the TLS secret with the required certificate files.

   To change the hostname and use the selfsigned certificate, see Prerequisites to prepare your cert and tls files.

7. Run the script from the operator namespace.

   ./cs-onprem-tenant-config.sh
   

   If you see the following error, it means that you did not provide the new certificate files for TLS secret in the installer_scripts directory. To resolve the issue, place the certificate files and run the script again.

   tls.key is not present in current directory, pls keep tls.key, tls.crt and ca.crt files in current directory
   

   The script completes the following tasks:

   • Uses namespaces from the common_service_maps configmap that is in the kube-public namespace. The common_service_maps` configmap has all the namespaces in a tenant.

   • Creates a TLS secret if you provided new certificate files.

   • If your cluster topology has a separate namespace for all operators, the script runs the iam-custom-hostname job in that namespace.

   • Update the custom hostname in all applicable identity management (IM) components.

8. Restart the Zen operator pod.

   oc get pod -n <your-foundational-services-namespace> | grep ibm-zen-operator
   

   oc delete pod -n <your-foundational-services-namespace> <ibm-zen-operator-pod-name>
   

9. Restart the usermgmt pods.

   1. Get the usermgmt pod names.

      oc get pods |grep usermgmt
      

   2. Delete the usermgmt pods.

      oc delete pod <usermgmt-pod-name>
      

10. Wait until the Zen operator and usermgmt pods restart. Ensure that the pods are in the ready and running status.

oc get pods -n <your-foundational-services-namespace> | grep ibm-zen-operator
oc get pods -n <your-foundational-services-namespace>|grep usermgmt

Result

After you run the script, the cp-console route is updated with the new hostname. You can also see the new certificates, if applicable, in your browser when you access the cp-console URL.