Creating secrets to protect sensitive Navigator configuration data

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

Procedure

  1. Prepare your security environment:
    Also create a secret for the security details of the LDAP directory and data sources that you configured in preparation for use with Navigator. Collect the users and passwords to add to the secret. When you add your values, note the following points:
    • The keystorePassword must be 16 or more characters when FIPS is enabled.
    • The PostgreSQL navigatorDBPassword must be 16 or more characters when FIPS is enabled.

    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 }}"
    Tip:
    1. The value that you specify for the appLoginUsername must be an existing LDAP user or a user defined in an external IdP 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 not preexisting values and they are used to create the passwords. The ltpaPassword that is set for the BAN secret must be the same as the ltpaPassword in the FileNet® Content Manager secret.
    2. 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 Navigator.
    Note: When you create secrets, special characters such as $, \, *, =, and ! are interpreted by your shell, and therefore need escaping. In most shells, the simplest way to escape a password is to surround it with single quotation marks ('). For example, if your password is S!B\*d$zDsb= then use single quotation marks around the password string:
    --from-literal=password='S!B\*d$zDsb='

    You do not need to escape special characters in passwords from files (--from-file). For more information, see Managing Secrets.

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

  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.