Configuring an external database

The ODM for production Helm chart provides Db2®, PostgreSQL, Microsoft SQL Server, and Oracle drivers. The customer is responsible for the backup and recovery process of these databases.

Use the following configuration parameters:

Server type: externalDatabase.type(db2, postgresql, sqlserver, or oracle)
Server name: externalDatabase.serverName
Port: externalDatabase.port
Database name: externalDatabase.databaseName
URL: externalDatabase.url (optional for Oracle. Example: "jdbc:oracle:thin:@serverName:port:databaseName")
Secret credentials: externalDatabase.secretCredentials
The secretCredentials parameter encapsulates the db-user and the db-password keys to access the database. You create the secret in the following way:
```
kubectl create secret generic <credentials-secret-name> \
--from-literal=db-user=<username> \
--from-literal=db-password='<password>'
```

For example:

externalDatabase:
      type: postgresql
      port: 5432
      secretCredentials: odm-prod-secret-psql-dc
      databaseName: dcdb
      serverName: postgresqldc.odm-restricted.svc.cluster.local

In this example, you configure a common Postgresql database for both Decision Server and Decision Center.

Note: You can provide your own driver to use your own database by setting the externalDatabase.driversUrl parameter. This parameter accepts a unique URL or a list of URLs. Each URL can link to a single JAR file, or to compressed files in the .zip, .tar, .tar.gz, .tar.bz2, or .tar.xz format with the following structure: jdbc/db2|postgresql|sqlserver/driver_files.

To set a list of values, use the following syntax:

--set externalDatabase.driversUrl="{url1,url2}"

Configuring a database with SSL

The SSL/TLS protocol is enabled by default to secure the database connection.

Choice 1: Configure a Db2 database instance.
If SSL is used to secure a Db2 database connection, create a secret by providing the tls.crt file that contains the Db2 certificate:
```
kubectl create secret generic db2-ssl-secret --from-file=tls.crt
```
Then, set the externalDatabase.sslSecretRef parameter to this db2-ssl-secret.

For more information about generating the SSL certificate, see Self-signing digital certificates.

Choice 2: Configure a PostgreSQL database instance.

There are two types of PostgreSQL SSL configuration:

Traditional password authentication with a driver that automatically retrieves the certificate
Certificate-based authentication

PostgreSQL supports certificate-based authentication for increased security of your connections. Certificate-based authentication is only available for SSL connections. Instead of a password, the client must provide a valid certificate.

Operational Decision Manager requires TLS version 1.2 to configure PostgreSQL on the server side. The verification level of the connection depends on the SSL mode (sslmode), as described in the following table.

Table 1. SSL modes
sslmode	Eavesdropping protection	MITM protection	Description
require	Yes	No	You want your data to be encrypted, and you accept the overhead. You trust that the network ensures you always connect to the server you want.
verify-ca	Yes	Depends on the Certificate Authority (CA) policy	You want your data to be encrypted, and you accept the overhead. You want to be sure that you connect to a server that you trust.
verify-full	Yes	Yes	You want your data to be encrypted, and you accept the overhead. You want to be sure that you connect to a server that you trust, and is the one that you specify.

For more information on the SSL modes, see https://jdbc.postgresql.org/documentation/ssl/.

To establish certificate-based authentication, you must create an SSL secret in the following way.

In require sslmode: The secret must contain at least the tls.key private key, and the tls.crt public key, in PEM format.

In verify-ca or verify-full sslmode: In addition to the two above keys, the secret must contain the ca.crt certificate of the PostgreSQL server Certificate Authority, in PEM format. Example:

kubectl create secret generic postgresql-ssl-secret --from-file=tls.crt \
                                            --from-file=tls.key \
                                            --from-file=ca.crt \
                                            --from-literal=sslmode=[require|verify-ca|verify-full]

To define the secret for the database connection, you do not need to specify a password. The db-user key is sufficient. Example:

kubectl create secret generic <odm-db-secret> --from-literal=db-user=<user_name>

Set the externalDatabase.sslSecretRef parameter to this postgresql-ssl-secret.

Choice 3: Configure an Oracle database instance.
To configure Oracle SSL, you must specify PROTOCOL=TCPS in the URL parameter.
For example:
```
"jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=servername)(PORT=2484))(CONNECT_DATA=(SERVICE_NAME=servicename)))"
```
You must also provide the Oracle certificate as described in Importing the certificate of an external service.

Targeting separate databases

You might want to target two separate databases for your Decision Server and Decision Center instances. To do so, you need to define decisionServer and decisionCenter tags under the externalDatabase parameter.

In the following example, Decision Center is configured with a Mysql database and Decision Server with a Postgresql database.

externalDatabase:
  decisionCenter:
    type: mysql
    secretCredentials: odm-prod-secret-msql-dc
    databaseName: sampledb
    serverName: mysql.odm-restricted.svc.cluster.local
    driversUrl: 
      - https://repo1.maven.org/maven2/mysql/mysql-connector-java/5.1.49/mysql-connector-java-5.1.49.jar
  decisionServer:
    type: postgresql
    secretCredentials: odm-prod-secret-psql-ds
    databaseName: dsdb
    serverName: postgresqlds.odm-restricted.svc.cluster.local

For more information about supported databases, see Detailed system requirements.