Creating secrets to protect sensitive Business Automation Navigator configuration data

Before you install Business Automation Navigator, create secrets manually to protect the configuration data you are going to enter.

1. Prepare your security environment:

   You must also create a secret for the security details of the LDAP directory and data sources that you configured in preparation for use with IBM Business Automation Navigator. Collect the users and passwords to add to the secret. Using your values, run the following command:

   kubectl create secret generic ibm-ban-secret \
     --from-literal=navigatorDBUsername="user_name" \
     --from-literal=navigatorDBPassword="xxxxxxx" \
     --from-literal=keystorePassword="xxxxxxx" \
     --from-literal=ltpaPassword="xxxxxxx" \
     --from-literal=appLoginUsername="user_name" \
     --from-literal=appLoginPassword="xxxxxxx" \
     --from-literal=jMailUsername="mailadmin" \
    --from-literal=jMailPassword="xxxxxxx" \
    -n "{{ namespace }}"

   The secret that you create, ibm-ban-secret, is the value for the parameter ban_secret_name.

   Tip: The value that you specify for the appLoginUsername must be an existing LDAP user that you want the Navigator to use for the administrator role when the configuration database schema is created. The values that you specify for keystorePassword and ltpaPassword are used to create the passwords.

   Note: Include the jMailUsername and jMailPassword values only if you are enabling the Sendmail capability in Navigator. These values are preexisting from your mail system configuration. XOR encryption can be used to protect the jMailPassword. For more information about the Sendmail capability, see Optional: Configuring Send Mail for IBM Business Automation Navigator.
2. Configure the root ca secret and trusted certificate list.

   The custom YAML file also requires values for the root_ca_secret and trusted_certificate_list parameters. The TLS secret contains the root CA's key value pair. You have the following choices for the root CA:

   • You can generate a self-signed root CA.
   • You can allow the operator (or ROOTCA ansible role) to generate the secret with a self-signed root CA (by not specifying one).
   • You can use a signed root CA. In this case, you create a secret that contains the root CA's key value pair in advance.

   The list of the trusted certificate secrets can be a TLS secret or an opaque secret. An opaque secret must contain a tls.crt file for the trusted certificate. The TLS secret has a tls.key file as the private key.

   You can generate a TLS secret with following command:

   kubectl create secret generic <ssl secret name> --from-file=tls.crt="<crt file in local>" -n "{{ namespace }}"
   
   

   In the <crt file in local> you can add multiple certificates like in the following example:

   -----BEGIN CERTIFICATE-----
   MIIGXTCCBU****
   Kwa==
   -----END CERTIFICATE-----
   -----BEGIN CERTIFICATE-----
   MIIGX****
   Kws==
   -----END CERTIFICATE-----
   -----BEGIN CERTIFICATE-----
   MIIG******
   Kwd==
   -----END CERTIFICATE-----