Creating secrets to protect sensitive PostgreSQL SSL configuration data

If you plan to use SSL for your PostgreSQL database, create a secret manually to protect the certificate data for the database.

About this task

The steps for creating the secret vary depending on whether your database enables server only or both server and client authentication.

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.

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	Network ensures that you always connect to the server you want.
verify-ca	Yes	Depends on the Certificate Authority (CA) policy	Network ensures you connect to a server you trust.
verify-full	Yes	Yes	Network ensures that you connect to the server 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 tls.key private key, and the tls.crt public key, the secret must contain the ca.crt certificate of the PostgreSQL server Certificate Authority, in PEM format. Example:

kubectl create secret generic <your-secret-name> \
--from-file=tls.crt=`<your-client-certification-name>.crt` \
--from-file=tls.key=`<your-client-key-name>.crt` \
--from-file=ca.crt=`<your-server-certification-name>.crt` \
--from-literal=sslmode=[require|verify-ca|verify-full]

In the <your-client-certification-name>.crt / <your-server-certification-name>.crt file, you can add multiple certificates like in the following example:

-----BEGIN CERTIFICATE-----
MIIGXTCCBU****
Kwa==
-----END CERTIFICATE-----
...
-----BEGIN CERTIFICATE-----
MIIGX****
Kws==
-----END CERTIFICATE-----

To define the secret for the database connection, you do not need to specify a password in ibm-fncm-secret secret. The DBUsername key is sufficient. For example:

kubectl create secret generic ibm-fncm-secret \
--from-literal=gcdDBUsername=<user_name> \

Make a note of the SSL secret name, so you can add it to the datasource_configuration section of the custom resource file, or enter it in the user interface if you use the OpenShift console.

What to do next

Use the name of your secret to create the configuration for an SSL database connection when you complete your CR YAML file.

The following values specify the SSL database configuration and provide the name of the SSL secret that you created:

dc_ssl_enabled: true
database_ssl_secret_name: "<postgresql ssl secret name>"

For example, for the relevant datasource for your IBM FileNet® Content Manager deployment, your CR might look like the following sample snip:

datasource_configuration:
    # the candidate value is "db2" or "db2HADR" or "oracle" or "sqlserver" or "postgresql"
    dc_ssl_enabled: true
    dc_gcd_datasource:
      dc_database_type: "postgresql"
      ...
      database_ssl_secret_name: "ibm-postresql-ssl-cert-secret"
    dc_os_datasources:
    - dc_database_type: "postgresql"
       ...
      database_ssl_secret_name: "ibm-postgresql-ssl-cert-secret"

Also remember to add the database user name and password to the ibm-fncm-secret.