Creating secrets

Edit online

Before you install a geo-redundant deployment of IBM® Netcool® Operations Insight® on OpenShift®, you must create secrets on your primary and backup clusters.

Note the following common variables that are needed to create secrets:

PRIMARY_NAME is the release name of the primary cluster.
PRIMARY_NAMESPACE is the namespace of the primary cluster.
BACKUP_NAME is the release name of the backup cluster.
BACKUP_NAMESPACE is the namespace of the backup cluster.

Create the following secrets on your primary and backup clusters for your geo-redundant deployment:

Cassandra

oc create secret generic ${PRIMARY_NAME}-cassandra-auth-secret \
      --from-literal=username=cassandraadmin \
      --from-literal=password=<my_password> \
      --namespace ${PRIMARY_NAMESPACE}
      
oc create secret generic ${BACKUP_NAME}-cassandra-auth-secret \
      --from-literal=username=cassandraadmin \
      --from-literal=password=<my_password> \
      --namespace ${BACKUP_NAMESPACE}

Coordinator service

oc create secret generic ${PRIMARY_NAME}-coordinator-api-secret \
      --from-literal=api_username=<api_username> \
      --from-literal=api_password=<my_api_password> \
      --from-literal=trust_store_password=<truststore_password> \
      --namespace ${PRIMARY_NAMESPACE}
      
oc create secret generic ${BACKUP_NAME}-coordinator-api-secret \
      --from-literal=api_username=<api_username> \
      --from-literal=api_password=<my_api_password> \
      --from-literal=trust_store_password=<truststore_password> \
      --namespace ${BACKUP_NAMESPACE}

OMNIbus

oc create secret generic ${PRIMARY_NAME}-omni-secret \
      --from-literal=OMNIBUS_ROOT_PASSWORD=<my_omnibus_ObjectServer_password> \
      --namespace ${PRIMARY_NAMESPACE}
      
oc create secret generic ${BACKUP_NAME}-omni-secret \
      --from-literal=OMNIBUS_ROOT_PASSWORD=<my_omnibus_ObjectServer_password> \
      --namespace ${BACKUP_NAMESPACE}

OMNIbus Web GUI

oc create secret generic ${PRIMARY_NAME}-was-secret \
      --from-literal=WAS_PASSWORD=<my_webgui_password> \
      --namespace ${PRIMARY_NAMESPACE}
      
oc create secret generic ${BACKUP_NAME}-was-secret \
      --from-literal=WAS_PASSWORD=<my_webgui_password> \
      --namespace ${BACKUP_NAMESPACE}

Kafka TLS

A CA certificate and key is needed to sign certificates for the Kafka brokers. This CA certificate and key must be on both sites to allow cross-site connections to be trusted. In the following examples, the CA certificate is myCertificate.crt and the CA certificate key is myCertificate.key. Generate a CA certificate and key, as in the following example:

CERTIFICATE_NAME=myCertificate
openssl genrsa -out ${CERTIFICATE_NAME}.key 2048
openssl req -new -x509 \
        -days 3650 \
        -key ${CERTIFICATE_NAME}.key \
        -subj "/CN=${CERTIFICATE_NAME} CA" \
        -out ${CERTIFICATE_NAME}.crt

Connect to the primary cluster and import the CA certificate and key that you generated.

oc create secret tls ca-cert \
      --cert=./myCertificate.crt \
      --key=./myCertificate.key \
      --namespace ${PRIMARY_NAMESPACE}

Connect to the backup cluster and import the same CA certificate and key that you generated on the primary cluster.

oc create secret tls ca-cert \
      --cert=./myCertificate.crt \
      --key=./myCertificate.key \
      --namespace ${BACKUP_NAMESPACE}

Kafka credentials

Create a secret to store the Kafka client credentials. This secret must be shared on both sites. The following examples contain simple values, you must choose more secure passwords for your deployment.

Connect to the primary cluster and create a secret to store the Kafka client credentials:

oc create secret generic kafka-client-credentials \
      --from-literal=username=<kafka-client-username> \
      --from-literal=password=<kafka-client-password> \
      --namespace ${PRIMARY_NAMESPACE}

Connect to the backup cluster and create a secret to store the same Kafka client credentials.

oc create secret generic kafka-remote-client-credentials \
      --from-literal=username=<kafka-client-username> \
      --from-literal=password=<kafka-client-password> \
      --namespace ${BACKUP_NAMESPACE}

Configuring additional networks

For a geo-redundant deployment of IBM Netcool Operations Insight on OpenShift, you need to configure certain additional networks to allow Cassandra to communicate between the two sites. The additional networks are defined as NetworkAttachmentDefinition objects, which are applied to the Cassandra pods when they are deployed. They provide an extra network interface to the Cassandra pods, in addition to the standard interfaces on the pod network.

Cassandra clients connect to Cassandra pods in the same cluster by using the default pod network. Cassandra pods talk to other Cassandra pods (internode communication) through the additional network interfaces, that is, for both communication in the same cluster or site and in between clusters or sites. You need a NetworkAttachmentDefinition per Cassandra pod, and each NetworkAttachmentDefinition defines a static IP address that is accessible and routable from either site. For more information about configuring additional networks, see https://docs.openshift.com/container-platform/4.8/networking/multiple_networks/configuring-additional-network.html.