Creating secrets to protect sensitive Document Processing configuration data

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

1. Prepare your ibm-adp-secret:
   Before you deploy, you must create a secret for the security details of the LDAP directory and data sources that you configured in preparation for use with Document Processing. Collect the users and passwords to add to the secret. Using your values, run the following command:

   kubectl create secret generic ibm-adp-secret
        --from-literal=serviceUser="uid=btsServiceUser,dc=example,dc=org" --from-literal=servicePwd="xxx" 
       --from-literal=serviceUserBas="uid=rrServiceUser,dc=example,dc=org" --from-literal=servicePwdBas="xxx" 
       --from-literal=serviceUserCa="uid=caServiceUser,dc=example,dc=org"  --from-literal=servicePwdCa="xxx" 
       --from-literal=envOwnerUser="uid=environmentOwner,dc=example,dc=org" --from-literal=envOwnerPwd="xxx"
       --from-literal=envOwnerUsername="environmentOwnerName"

   You must provide the envOwnerUsername parameter, except if your username is part of the LDAP DN(Distinguished Name), in which case you can skip this parameter.

   If you want to use your own Enterprise MongoDB instance in the environment, you must also include the mongoURI and your Mongo user and password values in the secret. In that case, use a command like the following example:

   kubectl create secret generic ibm-adp-secret
        --from-literal=serviceUser="uid=btsServiceUser,dc=example,dc=org" --from-literal=servicePwd="xxx" 
       --from-literal=serviceUserBas="uid=rrServiceUser,dc=example,dc=org" --from-literal=servicePwdBas="xxx" 
       --from-literal=serviceUserCa="uid=caServiceUser,dc=example,dc=org"  --from-literal=servicePwdCa="xxx" 
       --from-literal=envOwnerUser="uid=environmentOwner,dc=example,dc=org" --from-literal=envOwnerPwd="xxx"
       --from-literal=mongoUri="mongodb://mongo:<mongoPwd>@<mongo_database_hostname>:<mongo_database_port>/<mongo_database_name>?authSource=admin&connectTimeoutMS=3000"
       --from-literal=mongoUser="uid=mongo" --from-literal=mongoPwd="xxx"

   The secret you create, ibm-adp-secret, is the value for the parameter adp_secret_name.

2. Create a Kubernetes secret for the database credentials for Document Processing engine. If you are using Db2® database, go to step 3. If you are using PostgreSQL database, go to step 4.
3. Create a Kubernetes secret for the Db2 credentials for Document Processing.
   The contents of the secret depends on whether the Db2 connection does or does not use SSL.

   • If you use Db2 without SSL, create the Kubernetes secret with this command.

     kubectl -n $KUBE_NAME_SPACE create secret generic aca-basedb \
     --from-literal=BASE_DB_USER="$BASE_DB_USER" \
     --from-literal=BASE_DB_CONFIG="$BASE_DB_PWD" \
     --from-literal=${PROJ1_DB_NAME}_DB_CONFIG="$PROJ1_DB_PWD" \
     --from-literal=${PROJ2_DB_NAME}_DB_CONFIG="$PROJ2_DB_PWD"

     Where

     • $KUBE_NAME_SPACE is the namespace name. For example, caop.
     • $BASE_DB_USER is the user for the Document Processing engine's base database that you created in Preparing the Db2 databases.
     • $BASE_DB_PWD is the user password for the Document Processing engine's base database.
     • $PROJ1_DB_NAME, $PROJ2_DB_NAME, and so on are the names for your project databases. You must use all upper-case characters for the name. "_DB_CONFIG" is appended to the name to get the property.
     • $PROJ1_DB_PWD, $PROJ2_DB_PWD, and so on are the user passwords for each of the project databases, as applicable.
   • If you use Db2 with SSL, you need the SSL certificate file for your Db2 instance. Create the Kubernetes secret with this command.

     kubectl -n $KUBE_NAME_SPACE create secret generic aca-basedb \
     --from-literal=BASE_DB_USER="$BASE_DB_USER" \
     --from-literal=BASE_DB_CONFIG="$BASE_DB_PWD" \
     --from-literal=${PROJ1_DB_NAME}_DB_CONFIG="$PROJ1_DB_PWD" \
     --from-literal=${PROJ2_DB_NAME}_DB_CONFIG="$PROJ2_DB_PWD" \
     --from-file=CERT="$PATH_TO_DB2_SSL_CERTIFICATE_FILE"

     Where

     • $KUBE_NAME_SPACE is the namespace name. For example, caop.
     • $BASE_DB_USER is the user for the Document Processing engine's base database that you created in Preparing the Db2 databases for Document Processing.
     • $BASE_DB_PWD is the user password for the Document Processing engine's base database.
     • $PROJ1_DB_NAME, $PROJ2_DB_NAME, and so on are the project database names. You must use all upper-case characters for the name. "_DB_CONFIG" is appended to the name to get the property.
     • $PROJ1_DB_PWD, $PROJ2_DB_PWD, and so on are the user passwords for each of the project databases, as applicable.
     • $PATH_TO_DB2_SSL_CERTIFICATE_FILE is the filepath to the Db2 SSL certificate file.
4. Create a Kubernetes secret with SSL for PostgreSQL database with the following command:

   kubectl -n $KUBE_NAME_SPACE create secret generic aca-basedb \
   --from-literal=BASE_DB_USER="$BASE_DB_USER" \
   --from-literal=BASE_DB_CONFIG="$BASE_DB_PWD" \
   --from-literal=${PROJ1_DB_NAME}_DB_CONFIG="$PROJ1_DB_PWD" \
   --from-literal=${PROJ2_DB_NAME}_DB_CONFIG="$PROJ2_DB_PWD" \
   --from-file=CERT=$PATH_TO_PG_SSL_CLIENT_CERT_FILE \
   --from-file=KEY="$PATH_TO_PG_SSL_CLIENT_KEY_FILE" \
   --from-file=ROOTCERT="$PATH_TO_PG_SSL_ROOT_CERT_FILE"

   Where

   • $KUBE_NAME_SPACE is the namespace name. For example, caop.
   • $BASE_DB_USER is the user for the Document Processing engine's base database that you created in Preparing the Db2 databases for Document Processing.
   • $BASE_DB_PWD is the user password for the Document Processing engine's base database.
   • $PROJ1_DB_NAME, $PROJ2_DB_NAME, and so on are the project database names. You must use all upper-case characters for the name.
   • $PROJ1_DB_PWD, $PROJ2_DB_PWD, and so on are the user passwords for each of the project databases, as applicable. If your PostgreSQL server uses certificate authentication and does not require a password, you can provide an empty string for the password values.
   • $PATH_TO_PG_SSL_CLIENT_CERT_FILE is the filepath to the PostgreSQL SSL client certificate file.
   • $PATH_TO_PG_SSL_CLIENT_KEY_FILE is the filepath to the PostgreSQL SSL private key file.
   • $PATH_TO_PG_SSL_ROOT_CERT_FILE is the filepath to the PostgreSQL CA root certificate file.

   Note:

   • The lines that begin with --from-file=CERT and --from-file=KEY are needed only if the PostgreSQL server requires client authentication.
   • The line that begins with --from-file=ROOTCERT is needed only if you want to require server authentication. This is configurable in the custom resource by using the property datasource_configuration.dc_ca_datasource.dc_database_ssl_mode (See the PostgreSQL documentation).
5. If you have additional project databases in the property dc_ca_datasource.tenant_databases in the custom resource file, you must include the following line for each of the project databases:

   --from-literal=${PROJ_DB_NAME}_DB_CONFIG="$PROJ_DB_PWD"

6. Make sure that the data source configuration data for your devos1 and aeos data sources are included in the ibm-fncm-secret.
   For information on creating the ibm-fncm-secret, see Creating secrets to protect sensitive IBM FileNet Content Manager configuration data.