Managing 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 about the SSL modes, see https://jdbc.postgresql.org/documentation/ssl/.

Attention: Due to a dependency on JKS keystores, PostgreSQL JDBC data sources cannot use verify-ca or verify-full SSL options when FIPS is enabled. Use the require SSL mode option.
To establish a traditional password-based authentication, you must have a root Certificate Authority certificate (ca.cert) in PEM format and run the following command:
kubectl create secret generic <your-secret-name> \
--from-file=ca.crt=`<your-server-certification-name>.crt` \
--from-literal=sslmode=[require|verify-ca|verify-full] 

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 username and password to the ibm-fncm-secret.