Updating custom hostname and TLS secret by using a configmap

You can change the custom hostname and certificates for the cp-console route from the foundational services by using a job.

Before you begin

Determine your new hostname

To change the hostname, first you must create the new hostname. If you modify the domain from the default Red Hat OpenShift Container Platform (OCP) domain, ensure that the new hostname can resolve to the OpenShift router from inside and outside the OCP cluster.

Change the certificate

To change the certificate, you need to obtain the required certificate files in the proper format. The following files are required for that contains the certificates:

ca.crt: It 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: It contains only the route server certificate.

Note: The route server certificate needs to pass the TLS hostname verification for the hostname of the route.
tls.key: It contains the private key of the route server certificate.

Each of the certificates and the key must be in an unencrypted PEM format. The PEM encoding uses header and footer lines for each certificate and private key.

For example,
```
-----BEGIN CERTIFICATE-----
(encoded set of characters)
-----END CERTIFICATE-----

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

Create the secret

To change the certificate, you need to create the secret. Run the following command to create the secret:

 oc -n ibm-common-services create secret generic custom-tls-secret --from-file=ca.crt=<file path>/ca.crt  --from-file=tls.crt=<file path>/tls.crt  --from-file=tls.key=<file path>/tls.key

Note: When you use the custom certificates, you need to manage the lifecycle of the certificates in the secret that you created.

Procedure

1. Create the `cs-onprem-tenant-config.yaml` file

Create the cs-onprem-tenant-config.yaml file that contains the hostname and the certificate information. Include the appropriate settings in the data section of the cs-onprem-tenant-config.yaml file if you are changing the hostname or the certificates, or both. If you are changing the hostname, add the required hostname. If you are changing the certificate, do not change the name of the secret.

For example,

apiVersion: v1
kind: ConfigMap
metadata:
  name: cs-onprem-tenant-config
  namespace: ibm-common-services
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

2. Create the configmap

Create the configmap by using the cs-onprem-tenant-config.yaml file.

 oc apply -f cs-onprem-tenant-config.yaml -n ibm-common-services

3. Apply the changes

Create the iam-custom-hostname.yaml file and run the following command to update the settings:

 oc apply -f iam-custom-hostname.yaml -n ibm-common-services

The iam-custom-hostname.yaml file contains the following content:

apiVersion: batch/v1
kind: Job
metadata:
  name: iam-custom-hostname
  namespace: ibm-common-services
  labels:
    app: iam-custom-hostname
spec:
  template:
    metadata:
      labels:
        app: iam-custom-hostname
    spec:
      containers:
      - name: iam-custom-hostname
        image: quay.io/opencloudio/iam-custom-hostname:v0.1
        command: ["python3", "/scripts/saas_script.py"]
        imagePullPolicy: Always
        env:
          - name: OPENSHIFT_URL
            value: https://kubernetes.default:443
          - name: IDENTITY_PROVIDER_URL
            value: https://platform-identity-provider:4300
          - name: PLATFORM_AUTH_URL
            value: https://platform-auth-service:9443
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                apiVersion: v1
                fieldPath: metadata.namespace
          - name: WLP_CLIENT_ID
            valueFrom:
              secretKeyRef:
                key: WLP_CLIENT_ID
                name: platform-oidc-credentials
          - name: WLP_CLIENT_SECRET
            valueFrom:
              secretKeyRef:
                key: WLP_CLIENT_SECRET
                name: platform-oidc-credentials
          - name: OAUTH2_CLIENT_REGISTRATION_SECRET
            valueFrom:
              secretKeyRef:
                key: OAUTH2_CLIENT_REGISTRATION_SECRET
                name: platform-oidc-credentials
          - name: DEFAULT_ADMIN_USER
            valueFrom:
              secretKeyRef:
                key: admin_username
                name: platform-auth-idp-credentials
          - name: DEFAULT_ADMIN_PASSWORD
            valueFrom:
              secretKeyRef:
                key: admin_password
                name: platform-auth-idp-credentials
      restartPolicy: OnFailure

Note: If you are using an air-gapped installation, you need to mirror the job image to your local repository.

4. Restarting `operand-deployment-lifecycle-manager` pods

After the job is completed and the route is updated, restart operand-deployment-lifecycle-manager pods.

 oc -n ibm-common-services delete pod -l name=operand-deployment-lifecycle-manager

5. Manually restarting the pods if the `usermgmt` pods exist in any Cloud Pak namespace

If the usermgmt pods exist in any Cloud Pak namespace, like when you use IBM Automation Foundation, you need to manually restart the pods. The usermgmt pods in the ibm-common-services namespace are restarted by the operator.

 oc delete pod -l app.kubernetes.io/component=usermgmt -n <cloudpak namespace>

After you complete the steps, you can see that the cp-console route is updated with the new hostname. You can also see the new certificates in your browser when you access the cp-console URL.