Configuring authentication

Edit online

Use this section to configure authentication between the components of your hybrid installation, by using secrets to contain passwords and configmaps to contain certificates.

Note: If you are configuring authentication for a high availability disaster recovery (HADR) hybrid deployment, point commands to the IBM® HTTPS Cluster. If you are configuring authentication for a regular hybrid deployment (without HADR), point commands to the WebGUI Server.

Overview of required secrets and configmaps

The secrets and configmaps described in Table 1 are needed for communication between services that are running on-premises, and services that are running in the cloud. The secrets that are required to access the on-premises services must be created manually. The secrets that are required to access the cloud services can be created manually, or can be generated automatically by the installer.

Note: Blank root password does not work for Omnibus and causes failures for Aggregation Normalizer pod and EA NOI Action Service pod.

Table 1: Secrets and configmaps required for a hybrid installation

Users requiring password	Secret or configmap	Data keys in secret	Gives access to a service that runs on cloud or on-premises.	Creation methods
OMNIbus root user	`release_name`-omni-secret	`omni_password`	On-premises	Manual
WebSphere® admin user	`release_name`-was-secret	`was_password`	On-premises	Manual
OAuth client ID	`release_name`-was-oauth-cnea-secrets	`client_id client_secret`	On-premises	Manual
	A configmap, named by the user, containing the WebSphere certificate.		On-premises.	Manual
	`release_name`-omni-certificate-secret	`password`	On-premises	Manual
`couchdb`	`release_name`-couchdb-secret	`password username=root secret=couchdb`	Cloud	Manual or automatic
`hdm`	`release_name`-cassandra-auth-secret	`username password`	Cloud	Manual or automatic
`redis`	`release_name`-ibm-redis-authsecret	`username password`	Cloud	Manual or automatic
`kafka`	`release_name`-kafka-admin-secret	`username password`	Cloud	Manual or automatic
`admin`	`release_name`-kafka-client-secret	`username password`	Cloud	Manual or automatic

Where release_name is the name that you will use for your cloud native components deployment in name (OLM UI install), or metadata.name in noi.ibm.com_noihybrids_cr.yaml (YAML View).

Creation of configmap for access to on-premises WebSphere Application Server.

Note: The virtual machine (VM) and Red Hat® OpenShift® Container Platform components of IBM Netcool Operations Insight® must be on the same top-level domain, for example, xyz.com. If these components are not on the same top-level domain, then the hybrid setup works only with the SameSite=None attribute, which is less secure than the SameSite=Strict attribute. Hence it is preferred to use the same top-level domain for the VM and Red Hat OpenShift Container Platform components instead of changing the SameSite attribute.

Create a configmap that contains the certificate for on-premises WebSphere and import this on to your cluster, so that the cloud native components can access WebSphere.

Get the signer certificate chain for DASH/WebGUI.

openssl s_client -showcerts -verify 5 -connect [host]:[port] < /dev/null | awk '/BEGIN/,/END/{ if(/BEGIN/){a++}; out="cert"a".pem"; print >out}'

In the command output, cert1.pem is the signed certificate and cert2.pem is the signer.

If using a load balanced setup, get the signer certificate chain for the load balancer.
Create a configmap containing the WebSphere certificate.
```
oc create configmap configmap-name --from-file=full-path-to-pem-certificate-file
```
Where
- configmap-name is the name of the configmap to be created, for example users-certificate. The operator property dash.trustedCAConfigMapName must match this value. For more information, see Hybrid operator properties.
- full-path-to-pem-certificate-file is the file name and path for the WebSphere certificate extracted in step 1.
If using a load balanced setup, use the certificate from the load balancer when creating the configmap.

Creation of secrets for access to on-premises services

Follow these steps to give the cloud native components on Red Hat OpenShift Container Platform access to the on-premises components. These secrets must be created manually.

Create a secret to enable cloud native components to access your on-premises ObjectServer.
```
oc create secret generic release_name-omni-secret --from-literal=OMNIBUS_ROOT_PASSWORD=omni_password --namespace namespace
```
Where
- release_name is the name that you use for your cloud native components deployment in name (OLM UI Form view), or name in the metadata section of the noi.ibm.com_noihybrids_cr.yaml file (YAML view).
- namespace is the name of the namespace into which you want to install the cloud native components.
- omni_password is the root password for the on-premises Netcool®/OMNIbus that you want to connect to.
Create a secret to enable the cloud native components to access the on-premises IBM Netcool/OMNIbus WebGUI.
```
oc create secret generic release_name-was-secret --from-literal=WAS_PASSWORD=was_password --namespace namespace
```
Where
- namespace is the name of the namespace into which you want to install the cloud native components.
- was_password is the WebSphere admin password for the on-premises WebGUI that you want to connect to.
Create a secret to enable on-premises components to authenticate with cloud native components by using OAuth.
```
oc create secret generic release_name-was-oauth-cnea-secrets --from-literal=client-id=client_id --from-literal=client-secret=client_secret --namespace namespace
```
Where
- release_name is the name that you use for your cloud native components deployment in name (OLM UI Form view), or name in the metadata section of the noi.ibm.com_noihybrids_cr.yaml file (YAML view).
- namespace is the name of the namespace into which you want to install the cloud native components.
- client_id is the name to use as your client-id. This value is used later in Installing the integration kit when you configure your on-premises Operations Management installation to connect to your cloud native components.
- client_secret is the name to use for your client secret. This value is used later in Installing the integration kit when you configure your on-premises Operations Management installation to connect to your cloud native components.
Create a secret to enable communication between the OMNIbus component of your on-premises Operations Management installation and the cloud native components. This secret is created differently depending on whether you require an SSL or non-SSL connection. Choose from the following options.

No SSL connection
If you do not require an SSL connection, then follow this step to configure a non-SSL connection between the OMNIbus component of your on-premises Operations Management installation and the cloud native components.
```
oc create secret generic release_name-omni-certificate-secret --from-literal=PASSWORD=password --from-literal=ROOTCA="" --from-literal=INTERMEDIATECA="" --namespace namespace
```
Where
- release_name is the name that you use for your cloud native components deployment in name (OLM UI Form view), or name in the metadata section of the noi.ibm.com_noihybrids_cr.yaml file (YAML view).
- password is a password of your choice.
- namespace is the name of the namespace into which you want to install the cloud native components.
Note: The ROOTCA and INTERMEDIATECA strings are null strings.

SSL connection
If you require an SSL connection because the OMNIbus component of your on-premises Operations Management installation uses SSL, or you want to have an SSL connection between the cloud native components and the on-premises Operations Management installation's ObjectServer, then follow these steps to configure authentication:
1. Configure OMNIbus on your on-premises Operations Management installation to use SSL, if it is not doing so already. To check, run the command oc get secrets -n namespace and check whether the secret release_name-omnicertificate-secret exists. If the secret does not exist and the OMNIbus components are using SSL, the following steps must be completed.
2. Extract the certificate from your on-premises Operations Management installation.
```
$NCHOME/bin/nc_gskcmd -cert -extract -db "key_db" -pw password -label "cert_name" -target "ncomscert.arm"
```
  Where
  - key_db is the name of the key database file.
  - password is the password to your key database.
  - cert_name is the name of your certificate.
3. Copy the extracted certificate, ncomscert.arm, over to the infrastructure node of your Red Hat OpenShift Container Platform cluster, or to the node on your cluster where the oc CLI is installed.
4. Create a secret for the certificate.
```
oc create secret generic release_name-omni-certificate-secret --from-literal=PASSWORD=password --from-file=ROOTCA=certificate --namespace namespace --from-literal=INTERMEDIATECA=""
```
  Where
  - release_name is the name that you use for your cloud native components deployment in name (OLM UI Form view), or name in the metadata section of the noi.ibm.com_noihybrids_cr.yaml file (YAML view).
  - password is a password of your choice.
  - certificate is the path and file name of the certificate that was copied to your cluster in the previous step, ncomscert.arm.
  - namespace is the name of the namespace into which you want to install the cloud native components.
  Note: If the ObjectServer is not named 'AGG_V', which is the default, then you must set the global.hybrid.objectserver.config.ssl.virtualPairName parameter when you configure the installation parameters later. For more information, see Hybrid operator properties.

Creation of secrets for access to cloud native components

If any of these passwords and secrets do not exist, then the installer automatically creates random passwords for the required passwords and then creates the required secrets from these passwords. After installation is successfully completed, the passwords can be extracted from the secrets. For more information, see Retrieving passwords from secrets.

If you want to create all the required passwords and secrets manually, use the following procedure instead.

If passwords do not exist for the users in Table 1, then create them. All passwords must have fewer than 16 characters, and contain only alphanumeric characters.

Use the following commands to create the required secrets:

oc create secret generic release_name-couchdb-secret --from-literal=password=couchdb_password --from-literal=secret=couchdb --from-literal=username=root --namespace namespace
oc create secret generic release_name-cassandra-auth-secret --from-literal=username=hdm_username --from-literal=password=interpod_password --namespace namespace
oc create secret generic release_name-ibm-redis-authsecret --from-literal=username=redis_username --from-literal=password=interpod_password --namespace namespace
oc create secret generic release_name-kafka-admin-secret --from-literal=username=ka_admin_username --from-literal=password=interpod_password --namespace namespace
oc create secret generic release_name-kafka-client-secret --from-literal=username=ka_client_username --from-literal=password=interpod_password --namespace namespace

Where

couchdb_password is the password for the internal couchdb.
hdm_username Default is hdm. Do not use cassandra.
interpod_password is the password for user interface communication between pods.
redis_username Default is redis.
ka_admin_username Default is kafka.
ka_client_username The default is admin.
release_name is the name that you use for your cloud native components deployment in name (OLM UI Form view), or name in the metadata section of the noi.ibm.com_noihybrids_cr.yaml file (YAML view).
namespace is the name of the namespace into which you want to install the cloud native components.

If you want to change a password after installation, see Changing passwords and recreating secrets.

Certificate rotation

Server and cluster certificates need to be regenerated manually each time one of the following milestones are reached.

Server certificates have expired.
Root Certificate Authority (CA) certs are renewed or refreshed.
Intermediate CA certs are renewed or refreshed.

To regenerate certificates, repeat the certificate setup steps.