Updating custom hostname and TLS secret by using a configmap

You can change the custom hostname and certificates for the cp-console route by running a script.

Note: These instructions are for changing only the cp-console route hostname and certificates.

Before you begin

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 router from inside and outside the Red Hat OpenShift cluster.
If you are updating the TLS secret, provide new certificates in an unencrypted PEM format. Place the certificates in the ${installer_scripts} folder. For more information, see Apply the updates to your cluster by running a script.
Note: Whenever 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 leads to 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

You can update the custom hostname with one of the following methods:

Updating a custom hostname using the script
Updating a custom hostname using the ibmcloud-cluster-info configmap

Updating a custom hostname using the script

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

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: <hostname>
  ##comment out or remove this setting if not changing the certificates
  custom_host_certificate_secret: custom-tls-secret

Create the cs-onprem-tenant-config configmap.

oc apply -f cs-onprem-tenant-config.yaml -n <your-foundational-services-namespace>

Apply the updates to your cluster by running a script, which is available with the CASE bundle. The CASE bundle is used for installing foundational services in a disconnected environment. For more information about installing the ibm-pak plug-in and downloading the bundle, see Installing your IBM Cloud Pak by mirroring Cloud Pak images to a private container registry (with ibm-pak plug-in).
1. Download the ${installer_scripts} folder in the CASE bundle. For information on downloading the scripts, see Downloading scripts for additional configuration from specific version CASE bundle.
2. Go to your downloaded ${installer_scripts} directory.
```
cd ${installer_scripts}
```
3. If you are providing new certificates for TLS secret, place the certificates in the ${installer_scripts} directory. When you run the script, it creates the TLS secret by using the certificate files that you provide.
4. If your cluster topology has a separate namespace for all operators, identify that namespace and set it as the default namespace. You must also update the script. For more information about operatorNamespace, see Parameters in the CommonService CR.
  1. Locate the operatorNamespace in the common-service CR.
```
oc describe commonservice common-service -n <your-foundational-services-namespace> | grep operatorNamespace
```
  2. Set the operatorNamespace value as the default namespace.
```
oc project <operatorNamespace-value>
```
  3. Set the following environmental variables:
    - $csNamespace - the control namespace where ibm-iam-operator is deployed.
    - $map_to_common_service_namespace - the data namespace where operands are created.
5. Run the script. If your cluster topology has a separate namespace for all operators, run the script from that 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:

Identifies your topology type: simple topology or separation of data (SOD) topology.
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.
Updates the custom hostname in all applicable identity management (IM) components.
Restarts the pods with the following labels:
- app=platform-auth-service
- app=platform-identity-provider
- name=ibm-zen-operator
- component=usermgmt

Updating a custom hostname using the `ibmcloud-cluster-info` configmap

Complete the following steps to update the custom hostname with the ibmcloud-cluster-info configmap:

Update the cluster_address and cluster_endpoint parameters in the ibmcloud-cluster-info configmap.

oc edit cm ibmcloud-cluster-info -n cpfs-data

The following is the sample ibmcloud-cluster-info configmap:

apiVersion: v1
data:
  cluster_address: <hostname>-cpfs-data.apps.ocp415-qb.cp.fyre.ibm.com.              
  cluster_endpoint: https://<hostname>-cpfs-data.apps.ocp415-qb.cp.fyre.ibm.com      
  cluster_kube_apiserver_host: api.ocp415-qb.cp.fyre.ibm.com
  cluster_kube_apiserver_port: "6443"
  cluster_name: mycluster
  cluster_router_http_port: "80"
  cluster_router_https_port: "443"
  im_idmgmt_endpoint: https://platform-identity-management.cpfs-data.svc:4500
  im_idprovider_endpoint: https://platform-identity-provider.cpfs-data.svc:4300
  proxy_address: cp-proxy-cpfs-data.apps.ocp415-qb.cp.fyre.ibm.com
kind: ConfigMap

Replace <hostname> with the custom hostname.

Wait for the IM pods to restart.

platform-auth-service-xxx
platform-identity-management-xxx
platform-identity-provider-xxx

Restart Zen pods with the following label:
```
name=ibm-zen-operator
component=usermgmt
```
1. Get the usermgmt pod names.
```
oc get pods |grep usermgmt
```
2. Delete the usermgmt pods.
```
oc delete pod <usermgmt-pod-name>
```
You can login to cp-console and cpd with the updated hostname after the restart of the Zen pods.

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.

Restore SAML

After you change the certificate, the Security Assertion Markup Language (SAML) connection breaks. You must update the SAML metadata with the new certificate information to restore the connection. For more information, see Identity and access management migration.

Reverting the updates

If you need to revert to the previous hostname and certificate, repeat the steps in Procedure by using the previous hostname.